EuroCD 3/EuroCD 3.iso/Communication/Citadel_BBS/Docs/install3.man

Text File | 1998-06-24 | 163.7 KB | 4,038 lines

                           C I T A D E L - 8 6

                                  V3.40

                           INSTALLATION MANUAL

                          Copyright 1989 - 1991

                               by Hue, Jr.

                         C-86 Test System Sysop

                            [phone]

                                91Oct07













































                         Table of Contents

     I. Introduction & Requirements  . . . . . . . . . . . . . . . .  2
        I.1 ... but first, a caveat. . . . . . . . . . . . . . . . .  2
        I.2 Introduction . . . . . . . . . . . . . . . . . . . . . .  2
        I.3 Requirements . . . . . . . . . . . . . . . . . . . . . .  3
     II. Installation  . . . . . . . . . . . . . . . . . . . . . . .  4
         II.1 Tickling DOS configurations  . . . . . . . . . . . . .  4
         II.2 Making your modem do the right thing . . . . . . . . .  4
         II.3 Citadel-86 Operating Procedures
                         (and other epic fantasies)  . . . . . . . .  5
              II.3.a Who's this masked Temporary file, anyways?  . .  6
         II.3 (con't)  . . . . . . . . . . . . . . . . . . . . . . .  6
         II.4 Other Data Files . . . . . . . . . . . . . . . . . . .  7
         II.5 EASE . . . . . . . . . . . . . . . . . . . . . . . . .  8
         II.6 The ole' configuration file  . . . . . . . . . . . . .  8
              II.6.a But first, a word on moral values ... . . . . .  9
              II.6.b Section 1 of CtdlCnfg.Sys . . . . . . . . . . . 10
                Part 1 of Section 1: Meaningless Miscellanea . . . . 10
                Part 2 of Section 1: Required Odd Stuff  . . . . . . 12
                Part 3 of Section 1: Data File Sizes . . . . . . . . 13
                Part 4 of Section 1: Data File Locations . . . . . . 14
                Part 5 of Section 1: Policy Options  . . . . . . . . 15
                Part 6 of Section 1: Modem Handling  . . . . . . . . 18
                Part 7 Video Options   . . . . . . . . . . . . . . . 22
              II.6.c Section 2 of CtdlCnfg.Sys . . . . . . . . . . . 22
              II.6.d Section 3 of CtdlCnfg.Sys . . . . . . . . . . . 32
         II.7 The Big Step -- Your first experience with CONFG . . . 36
         II.8 CTDL -- That Childhood Experience  . . . . . . . . . . 37
         II.9 When the inevitable happens  . . . . . . . . . . . . . 38
         II.10 Installation -- Advanced Topics . . . . . . . . . . . 38
              II.10.a Command Line options . . . . . . . . . . . . . 38
              II.10.b BAT files and program termination ERRORLEVELS. 40
              II.10.c Making BAT files and command line options
                                                     work for you  . 41
              II.10.d Result Code and Call Progress Detection  . . . 43
              II.10.d.1 Restrictions on Result Codes . . . . . . . . 46
              II.10.e Extreme options in CtdlCnfg.Sys  . . . . . . . 46
     III. Zenith Z-100 Notes . . . . . . . . . . . . . . . . . . . . 48
              III.1 Introduction . . . . . . . . . . . . . . . . . . 48
              III.2 Scary but Innocuous Behaviors  . . . . . . . . . 48
              III.3 Result Codes . . . . . . . . . . . . . . . . . . 48

     Appendix -- Exhibit copy of CtdlCnfg.Sys. . . . . . . . . . . . 50












                                    -1-






     I. Introduction & Requirements
        Hi.  This is the Citadel-86 Installation Manual.  This manual comes in
     three parts.  In the first part we hope to present a very short intro-
     duction to Citadel-86 and give you an idea of the requirements of running
     Citadel-86.

        The second part of the Manual will contain a comprehensive (we hope!)
     discussion of general operation of Citadel-86 and a step-by-step
     installation guide.

        The third section contains notes specific to the Zenith Z-100, as
     contributed by both the author of this manual and System Operators
     using Z-100s as their hardware platform.

        If you are looking for documentation covering the day to day operations
     of Citadel-86, please read OPER3.MAN.  Just ignore the blood spots
     in there ...

     I.1 ... but first, a caveat.
        Citadel-86 has a number of eccentricities in it; in fact, some people
     might describe it as one giant eccentricity, and an explanation is,
     perhaps, in order.  One of the authors of this manual, Hue, Jr., is also
     the principal porter and caretaker of Citadel-86.  Citadel-86 derives
     directly from the version 2.10 of Citadel written by Cynbe ru Taren for
     CP/M, and contains a number of the apparent oddities that originally
     appeared in Cynbe's code.  Hue, Jr., feeling there may have been
     certain reasons in Cynbe's mind for what he did, has been somewhat loathe
     to change how certain things worked.  This may indicate a certain lack of
     ambition on his part; if so, so be it.  Whatever the case, he has chosen
     to leave them in, due to his faith in Cynbe knowing what he was doing.

     I.2 Introduction
        Citadel-86 is part of a growing family of BBSes characterized as
     "room-based" systems.  These systems are excellent messaging systems in
     which the message base is partitioned into various 'areas', enhancing the
     focus of the topics on the installation (if well-managed); the areas are
     usually termed 'rooms' in order to provide a highly familiar metaphor for
     the common user.

        Some room-based systems have an additional structure added on to them,
     known sometimes as 'hallways' or 'floors', which give addition focus.
     Citadel-86 has a 'floor' capability, which is optionally available to the
     users.  Floors allow the sysop and aides to partition the collection of
     rooms into 'subject floors' (or 'topical floors'), so rooms may be
     grouped as needed.

        Room-based systems normally feature an extremely streamlined set of
     commands, in which those used the most often are mnemonic 'single-stroke'
     commands whereby the user supplies the first letter of the command to
     execute and the system provides the rest of the command.  The speed
     and ease-of-use of such a command set, in conjunction with the room
     concept, has combined to make room based systems extremely popular and
     heavily used in several sections of the United States.

        Citadel-86 also has file upload and download abilities, integrated
     with the room metaphor, and a network capability.



                                    -2-






     I.3 Requirements
        There are a number of requirements connected with running a Citadel-86
     system. The most important one, though, is perhaps the most ignored, and
     that is experience with Citadel-86 or similar BBS software from a user
     standpoint.  It can't be stressed enough that you should have at least a
     month of day-to-day experience with Citadel-86 as a normal user, learning
     the various commands relating to messages and files, and in general
     becoming not only familiar, but comfortable with the Citadel-86 style of
     bbsing before descending into sysopdom.

        More formally, Citadel-86 is capable of running on two classes of
     machine.  The first is the Zenith Z-100, an 8085/8088 machine.  The
     second category contains the IBM PCs, ATs, and close clones (note
     a Z-100 does NOT constitute a close clone, although it is supported).
     These two classes are similar enough that we do not need to discuss the
     requirements for each class separately.  However, please note the
     two different machines require different executable files (unlike earlier
     versions of Citadel-86).

      o Operating System: PC- or MS- DOS 2.x or 3.x is required.  While not
        every single version of DOS between 2.x and 3.x range has been
        tested with Citadel-86, we have not had any reports of problems with
        those versions of DOS.  Version 1.x of MSDOS is a NO NO!

      o RAM: We suggest at least 350K RAM be made available to Citadel-86.
        This is in addition to RAM for MS-DOS, TSR programs, etc.

      o Disk storage: A hard disk is, naturally, highly desirable.  However,
        you can run Citadel-86 on a two floppy system, but if you must do so,
        you should also try to make sure you can have a relatively large
        RAM disk available; due to Citadel-86's structure, disk access is
        quite frequent.  While hard drives (and RAM drives!) do not mind
        frequent disk accesses, floppy drives have been known to burn out
        under constant usage unless certain options concerning RAM drives
        are taken advantage of within Citadel-86.

      o An auto-answer modem and the hardware (cables, etc.) requisite to hook
        it up to your computer:  While a Hayes or compatible is by far the most
        popular modem in usage, Citadel-86 can be configured to use several
        other types of modems.

      o A copy of the Citadel-86 software:  Typically, Citadel-86 comes in the
        form of three archives.  The first is called RUNTIME.LZH, and is
        absolutely necessary.  It contains the required executables to bring
        Citadel-86 up, various help files, and a configuration file.  The
        second is called SUPPORT.LZH, and contains what little documentation is
        available for Citadel-86.  It is not strictly necessary, but
        useful (or at least comforting).  The third is called UTIL.LZH (and
        sometimes comes as two archives), and contains the utilities available
        for Citadel-86.  (If you don't have these, they may possibly be on Test
        System in a room called Necessities].)

      o Some patience!






                                    -3-






     II. INSTALLATION
        In this section we explore the installation procedure for Citadel-86,
     investigating territory ranging from a general overview of the operating
     procedures of Citadel-86 to the details of setting up a system.

        We'll begin with a very short section on DOS and modem configuration.
     Then we get to the red, raw meat of Citadel-86: a description of how to
     prepare and operate Citadel-86, and a discussion of the data files
     Citadel-86 needs or generates.  Next will be a walk-through of actually
     setting up a basic Citadel-86 installation, at the end of which you should
     have a working Citadel-86 system.

        Easy, right?

     II.1 Tickling DOS configurations
        First comes the only required DOS configuration you must perform.  You
     must place the line "FILES=20" in your CONFIG.SYS file on your boot disk.
     If such a line already exists (or more than 20 is specified),
     then you don't need to worry about anything.  If such a line doesn't
     exist, then please put it into CONFIG.SYS, save the file, and reboot your
     system so it'll take effect.  IF YOU DON'T, CITADEL WILL BE VERY PEEVISH!

        If you don't understand what we're gabbing about, then please consult
     your DOS manuals.  CONFIG.SYS is an important part of the DOS system; it
     will do you good to learn what it's about.

        We AREN'T going to discuss DOS batch files in here.  We'll leave that
     for a later advanced section, because Citadel-86 exits with different
     ERRORLEVELs; the exact levels vary with the reason Citadel-86 exited.
     We feel it would be better not to cause excess confusion now, because
     you'll be confused soon enough as it is.

        We AREN'T going to discuss Citadel-86 command line parameters here,
     either.  While such things exist, we deem these to be the subject of an
     advanced section, and so we leave them for later attention in this manual.

     II.2  Making your modem do the right thing
        The Citadel-86 basic requirements in the area of modems are:

      o Modem can be hooked up to the computer
      o Modem can auto-answer the phone
      o Modem supports true carrier detect (very preferably on pin 8)
      o Modem can be hung up

        That sounds pretty darn basic, and it is.  However, if you want to take
     advantage of some of the default configurations of Citadel-86 for the
     modem, here's what we suggest for your modem in terms of characteristics:

      o Hayes or (semi) compatible

     or

      o Carrier detect on pin 8 (normal for most modems)
      o Carrier hangs up modem when DTR is dropped





                                    -4-






        Like we said, Citadel-86 is not restricted to Hayes/compatible
     modems, although they are of course the most popular modem used.  But
     other modems, such as TransModems, have been used successfully with
     Citadel-86. This makes our job, as the manual writers, substantially
     more difficult. Due to the overwhelming popularity of the Hayes compatible
     modems, we're going to confine most of our advice on modem configuration
     to Hayes and compatibles.

        The first thing to bear in mind is "compatible" is often a
     slippery term.  Our advice is based on our own experience with our Hayes
     compatible modems; if what we say doesn't seem to jibe with your modem's
     documentation, then use a little imagination and search the manuals.

        Hayes modems are not normally correctly configured fresh from the
     factory, so you must configure yours.  Usually, a combination of two
     methods are used to achieve the correct configuration.  First, DIP
     switches on the modem usually control several different functions,
     including auto-answer mode.  However, on some Hayes compatibles they
     don't exist; the functions they usually serve are then either accessed
     via software, or not at all. Second, (as you might have guessed), software
     can be used to configure the modem, through the use of AT commands.

        We strongly suggest you have your modem manual available at this
     point.

        First, you want to make sure your modem will drop carrier when DTR
     is dropped; the opposite of this is sometimes called the "forced DTR"
     function, and can be found in the DIP switches.  Make sure the modem
     does not have "forced DTR" on.

        Next, you need to ensure the modem is not "forcing carrier
     detect". Instead, it should only have carrier detect true when there is
     actually a caller online; otherwise your Citadel-86 will not work
     correctly.

        Finally, you want to make sure the modem will auto-answer when
     Citadel-86 is up.  This can be selected either by DIP switch or through
     software.  If you have a modem with a DIP switch controlling this
     function, you may want to use software instead, for finer control of
     how your modem acts.  You'll find later in this manual you can
     specify a string of commands to be sent to the modem when Citadel-86 first
     comes up, which you can use to activate auto-answer mode.

        The above comments apply equally well to non-Hayes compatible modems,
     although the details of how to initialize the modem will differ greatly.

        More detail on initialization of the modem will appear later in this
     manual in Section II.6.b: Part 6 of Section 1: MODEM HANDLING.

     II.3 Citadel-86 Operating Procedures (and other epic fantasies)
        Citadel-86 comes with a whole mess of files.  However, only three of
     these files are important, because they constitute the beginnings and
     necessities of Citadel-86.  They are:






                                    -5-



      o CtdlCnfg.Sys.  This file will contain your description of how you want
        your system set up.  Decisions concerning the location of important
        data files, system policies, and other semi-arcane things are described
        for Citadel-86's use.  The CtdlCnfg.Sys accompanying your system is a
        template of a very generic system, and we plan to guide you through it
        later in this manual.

      o CONFG.EXE.  This executable program digests CtdlCnfg.Sys, converting
        the information contained therein into a form far easier to
        digest by computer programs.  It is also responsible for generating new
        data files when necessary (typically only when a new system is first
        built!) and analyzing old data files.  It produces a highly temporary
        yet necessary file called CTDLTABL.SYS.

      o CTDL.EXE.  This is the main executable program of Citadel-86.  It
        expects to find CTDLTABL.SYS (remember the name?).  If it finds it, it
        reads it, erases it, and then continues to try to bring up the rest of
        the system, using the information it found in CTDLTABL.SYS.  If
        there are no severe abnormalities during CTDL.EXE's use, it will write
        a new version of CTDLTABL.SYS for use the next time you bring up
        CTDL.EXE.

     II.3.a Who's this masked Temporary file, anyways?
        CTDLTABL.SYS has been passed off so far as a temporary file, generated
     by CONFG.EXE from digesting CtdlCnfg.Sys, and required by CTDL.EXE.
     However, for a mere temporary file it merits more discussion.  We said
     CTDL.EXE expects to find it; you may have figured out if it's
     not there, then CTDL.EXE won't function properly.  This is correct, and
     the proper corrective action is to run CONFG.EXE.  DON'T TRY TO USE AN OLD
     VERSION OF CTDLTABL.SYS THAT YOU MAY HAVE SAVED IN CASE OF A CRASH!  Yes,
     we know running CONFG.EXE to generate a new CTDLTABL.SYS can take a
     while if you're running a big system.  We mentioned CONFG.EXE
     analyzes data files; as it happens, the results of this analysis is
     also placed in CTDLTABL.SYS, and used to enhance access to various parts
     of Citadel-86, such as the log.

        If you use an old version of CTDLTABL.SYS, the older information can
     cause Citadel-86 to look for messages that no longer exist, lose track of
     new rooms and log accounts, and other behaviors a sysop generally
     finds disruptive to domestic tranquility.  So, really, "Just say no."  Run
     CONFG.EXE if you lose your current CTDLTABL.SYS through a crash or power
     loss.  (This can be automated.  See section II.9 for advice on
     batch files.)

     II.3 (con't)
         Back to the subject.  We now know the purposes of the three primary
     files of Citadel-86.  CtdlCnfg.Sys contains information only the
     sysop can supply; CONFG.EXE processes CtdlCnfg.Sys, producing CTDLTABL.SYS
     and other data files; CTDL.EXE requires CTDLTABL.SYS, and constitutes
     the main executable of Citadel-86.

         So, in short form, here's how you run Citadel-86:

      o Modify CtdlCnfg.Sys to taste.
      o Run CONFG.EXE.
      o Run CTDL.EXE as many times as desired, as long as each run is
        terminated normally.

        If you crash, either from a fatal bug or power loss or whatever, just
     run CONFG.EXE again.


                                    -6-





     II.4 Other Data Files
        When you run CONFG.EXE for the first time, a number of data files are
     created, and they're what we're going to talk about in this section.
     These files contain the information -- accounts, rooms, messages, and
     other things -- making up any BBS.  The capacities of these files are
     selectable by the sysop, and once selected they remain the same size as
     CTDL.EXE runs (don't panic, though -- they can be changed through the use
     of Citadel-86 utilities!).  And with no more delay....

      o CTDLMSG.SYS.   This file contains all the messages in the system.
      o CTDLROOM.SYS.  This file contains information about the rooms in your
                       system.  The size of this file is given later in this
                       manual.
      o CTDLLOG.SYS.   This file contains all the accounts for users on your
                       system.  The size of this file is given later in this
                       manual.
      o CTDLNET.SYS.   This file, if it exists, will be 0 bytes long when
                       initially generated by CONFG.EXE, and will grow as
                       the network grows (NETWORK3.MAN talks about C86Net).
      o CTDLFLR.SYS.   This file contains information about the floors in your
                       system.  It grows as you add floors to your system.
                       Don't panic, though.  Each floor only takes 21 bytes.

        These, however, are not the only data files associated with Citadel-86.
     CTDL.EXE may, on occasion, generate data files also.  These files, unlike
     those generated by CONFG.EXE, are not static; however, they are almost
     always very small.

      o CTDLARCH.SYS.  This file contains data about auto-archiving of rooms
                       (an advanced topic covered in OPER3.MAN.)
      o CTDLNET.SYS.   This file, created by CONFG.EXE, will be expanded by
                       CTDL.EXE if you are participating in a network.
      o CALLLOG.SYS.   This file, an optional text file, is updated as each
                       caller hangs up.  See #AUDITAREA.
      o CTDLDIR.SYS.   This file contains data about the directory rooms on
                       your system, specifically the name of the DOS directory
                       associated with each directory room on your system.
      o CTDLMODR.SYS   This file contains data about the room moderators on
                       your system.
      o CTDLFWD.SYS    This file contains information about mail forwarding
                       by individual users if you are on the net.
      o FILELOG.SYS.   This file, another optional text file, is updated as
                       users upload and download files. See #AUDITAREA.
      o DOORUSE.SYS.   This file, another optional text file, is updated as
                       users use your doors.  See #AUDITAREA.
      o Net Files.     CTDL.EXE also generates a variety of small network
                       files, both temporary and permanent, for internal use.
                       See NETWORK3.MAN for more information on these files
                       (Appendix B).

         There are also the collection of help files accompanying Citadel-86,
     which we talk about in OPER3.MAN.








                                    -7-




     II.5 EASE!
        Released sometime in the last half of June, 1989, Citadel-86 Sysops
     have an alternative to the normal method of both constructing a new
     Citadel-86 installation and modifying the system.  This is the EASE
     utility program, which should be in its own archive, EASE.LZH.

        As we indicated above, Citadel-86's description file is CtdlCnfg.Sys
     which the Sysop must modify before installing a new system.  Although not
     a particularly wearisome task in itself, it can still be something of
     a pain to a new sysop as well as the more experienced sysop.  For this
     reason, and, hey, just for the fun of it, the EASE program has been
     provided.  EASE is just what it's named: it will ease both the
     installation and modification processes.

        At this point we'd like to urge you to do two things if you have EASE.
     First, read, perhaps swiftly, section II.6 below to get a feel for what is
     in CtdlCnfg.Sys, but don't try to modify the generic CtdlCnfg.Sys, nor
     should you try to initialize a new system, despite the suggestions below.
     Second, copy EASE.EXE, EASE.HLP, EASE2.HLP, MODEMS, CONFG.EXE,
     CtdlCnfg.Sys and CTDL.EXE into the directory in your system which will be
     the home directory for your installation.  Once you have done so, simply
     type EASE and follow the directions.  At the end of EASE, the system will
     hopefully be initialized with a complete CtdlCnfg.Sys and most of the
     data files you need, and you'll be ready to start playing -- far faster
     than the traditional form of installation for Citadel-86.

        To summarize, and if you have a hard drive:

     o Make a directory on the drive where you want your Citadel-86 installation
       to reside.
     o CD into that directory
     o Copy CONFG.EXE, CTDL.EXE, EASE.EXE, EASE.HLP, and the generic
       CtdlCnfg.Sys file into the directory (or deARC, or whatever it takes
       to get them into there).
     o Type EASE at the command line.  Follow the directions.  Be ready to
       refer to this documentation if you become confused.

        And remember.  EASE is not only for installation, but for modification
     as well.  Explore!

     II.6 The ole' configuration file
        So... we're done with the dull, but necessary, overview.  Now we get
     down to the fun stuff, the screechy details of deciding those system
     policies that can be enforced through the Citadel-86 software, where
     certain data files or groups of data files will be kept on your system,
     and some other details.  We do this by editing the file CtdlCnfg.Sys
     mentioned earlier in this manual, so you may want to haul out your editor.

        Or you may not.  Instead, it might be better to first read through this
     section along with a printout of CtdlCnfg.Sys, (we've included a copy of
     it in this file as well; see pages 35-42) comparing, taking notes,
     understanding what is required and what questions you will have to answer
     in order to set up your Citadel-86.

        Or -- and we recommend this -- you may wish to use EASE, the Citadel-86
     installation and modification program.





                                    -8-






        We've decided to divide the CtdlCnfg.Sys file into four sections in
     this manual.  The first section covers the utter necessities which must be
     set correctly for Citadel-86 to come up, options you cannot shut off,
     and some miscellaneous doodads not strictly required for a basic
     system, but we'd like you to set anyway.  This first section makes up
     the bulk of the CtdlCnfg.Sys parameters, and is the only one you must
     fill out in order to bring up Citadel-86; the rest of the sections
     contain options unnecessary for a basic Citadel-86 (although, of course,
     they ARE useful!).  If you're using a 'virgin' copy of CtdlCnfg.Sys, the
     options in the rest of the sections have been set to what we feel are
     harmless values.

         The second section is made up of options useful, but not necessary,
     for the operation of Citadel-86.

        The third section is made up of options related to Citadel-86's C86Net
     support.

        The fourth section covers extremely optional parameters designed to
     make modem handling very flexible when necessary.  (Don't read this
     unless you have a captive, well-fed assembly-language programmer nearby.)

     II.6.a But first, a word on moral values ...
        There are two methods values are set in CtdlCnfg.Sys.  One method
     is related to our reference to the fourth section, above, and will
     thus be covered in that advanced section.  The other method for setting
     parameter values, used with the rest of CtdlCnfg.Sys, looks like this:

     #<parameter name> <parameter value>

        The '#' MUST be in the left-most column of the file in order for
     CONFG.EXE to recognize it as a parameter. Indenting this line a space
     provides an easy way to disable or save an old value when experimenting
     and causes CONFG.EXE to ignore the line.

        A parameter value will usually either be a numerical value or a string
     value, and we'll tell you for each parameter whether your selection should
     be numerical or a string.  When it is numerical, always use decimal (with
     the exception of the mysterious fourth section).

        String values are always enclosed in quotes.  Most string values are
     used to indicate where to find certain files, but some string values are
     special in that certain hard-to-express codes may need to be used in order
     to accomplish something; this occurs almost exclusively when communicating
     with odd modems (such as TransModems).  Therefore, certain parameter
     string values in CtdlCnfg.Sys will allow formatting "directives" to be
     placed within them, which will be interpreted during the execution of
     CTDL.EXE to do special things.  The general format of a directive is a
     backslash ('\') followed by a either a character indicating a specific
     action, or a sequence of three digits representing an OCTAL value you may
     need to be in this particular position to accomplish what you wish to
     accomplish. Here is the list of characters that perform special actions
     when following a backslash:

            n: CR-LF
            t: Tab character
            b: Non-destructive Backspace


                                    -9-




            r: CR
            f: Formfeed
            ": Put out a quote (allows quotes to appear in your strings)
            \: Backslash

     So, if you wanted to insert a CR/LF into a string value, you would type

             "...\n..."

     If you needed to have the binary value of 6 in a string value, you would
     type

             "....\006...."

        Not all parameter string values accept these formatting directives;
     those that don't will simply ignore them.  We have marked those parameters
     accepting them both in this manual and in CtdlCnfg.Sys.  (OCTAL
     values, you say! Well.... the gentleman who donated the code to do the
     formatting directives, a certain Dalnefre' of SynTel, is a C hacker, and
     did it that way.  We feel it might be worth changing sometime in
     the future, too.)

        Please keep in mind that the '\r' has an added implication when placed
     in a CtdlCnfg.Sys string being sent to the modem.  Citadel-86 will pause
     for a full second after sending it in most situations.  This allows the
     sysop to send multiple commands to those modems using carriage returns as
     command delimiters, since the one second pause will give the modem time
     to digest the command.  For instance, "ATZ\rATS0=1\r" sent to Hayes-style
     modems would cause Citadel-86 to send "ATZ\r", pause for a full second
     during which the modem would reset to its power-up state (or at least for
     most Hayes clones it will), and then send the "ATS0=1\r", which activates
     the modem's auto-answer mode.  Please note this special processing of '\r'
     only applies to modem initialization and reinitialization strings, not to
     all strings.

        One more note.  Certain of the string values in CtdlCnfg.Sys end up
     being printed to the users via Citadel-86's formatter.  In these cases,
     when you use the CR/LF formatting directive ("\n"), remember to have a
     space follow it -- otherwise, Citadel-86's formatter probably won't send
     a CR/LF to the caller's terminal!

        Finally, you'll find a couple of parameters affect your installation
     simply by their very existence in your CtdlCnfg.Sys.  So that makes three
     ways to set values.

     II.6.b Section 1 of CtdlCnfg.Sys
        We're finally looking at CtdlCnfg.Sys.  The file starts (or at least
     our virgin copy does) with a short introduction to itself, which basically
     tells you to consult this manual if you find it too terse.  A short list
     of supported formatting directives is also included.

     Part 1 of Section 1: MEANINGLESS MISCELLANEA

        We're going to start Section 1 with some miscellaneous parameters.







                                    -10-





     ------
     #nodeTitle
        The first parameter you should find is called nodeTitle. It is a string
     value obeying formatting directives, and is subject to formatting
     considerations.  nodeTitle is the title of your installation printed when
     carrier is detected on your system.  More precisely, nodeTitle will show
     up in the following place on your system:

      Welcome to <#nodeTitle>
       Running ...

     However, nodeTitle may not necessarily be printed at this point.  After
     successfully bringing your system up, please consult OPER3.MAN's section
     on Help Files for more information on banner options.  EXAMPLE:

     #nodeTitle "Test System\n Truly a Heaven in Reverse"

     The #nodeTitle is printed out on .Read Status commands, also.  There is no
     formal limit on the length of this parameter.

     ------
     #nodeName
        nodeName is, in reality, purely a network parameter, and if you have no
     plans to ever join a C86Net, then there is no need to fill in this
     parameter.  However, it has always been traditional, even before there was
     a net for any Citadel system anywhere, to fill in this and the next
     parameter (and, so, sentimentally we feel this belongs in this
     Miscellaneous section).   nodeName is a string value which does NOT accept
     formatting directives (i.e., formatting directives will be ignored).  It
     can be no longer than 19 letters long.  It should be a short, mnemonic
     name for your system.  An EXAMPLE of a reasonable value:

     #nodeName "ODD-DATA"            -- The original Citadel

     If you ever do join a C86Net, messages from your system appearing on
     another Citadel-86 node will look something like this

        82Nov23 from Cynbe ru Taren @ODD-DATA

     except ODD-DATA would be replaced with your value for #nodeName.

     ------
     #nodeId
        As mentioned, this parameter is a network parameter that has
     traditionally always been set, even for non-network Citadels.  If you have
     no plans to ever be on a C86Net, then you don't have to set this string
     value parameter to anything important.  If you do plan to join one,
     though, (we'll go over this in more detail in the section on the network),
     then you do have to set this parameter correctly.  The format of this
     parameter is

          "<Country code><Area Code><Phone number>"

     all of which applies to the phone your system resides on.  Country
     code is a two letter sequence indicating what country you live in (US is
     the United States, CA is Canada.  Other country codes may be found in
     COUNTRY.DOC). Area code is the area code of your system (yes,



                                    -11-




     we are aware there is a clear bias towards US-style telephony).  And
     Phone number is, of course, the phone number your system is on.  You
     can put punctuation (such as parenthesis and dashes), but please be
     conservative with them.  This string value does not obey formatting
     directives.  Here's a fairly generic example:

     #nodeId "US [phone]"          -- Some system somewhere

     ------

     Part 2 of Section 1: REQUIRED ODD STUFF

     ------
     #baseRoom
        OK, now we're out of the miscellanea and into parameters you have
     to set, starting with baseRoom.  Citadel-86 always has a minimum of three
     rooms, the Aide> room for housekeeping, the Mail> room for private
     correspondence, and the <baseRoom>, which is the room a caller is
     always initially placed in.  (Historical note: the old CP/M Citadel called
     this room the Lobby>; we've only made the name of the Lobby> selectable by
     the sysop.)  This parameter is a string value obeying formatting
     directives and goes through the Citadel-86 formatter, and you must limit
     yourself to 19 characters or less for this value. And one more note --
     Citadel-86 will append the '>' to this name when it prints the room prompt
     for this room, you don't have to put it in yourself. If you wished to
     emulate the old CP/M Citadel, you'd set baseRoom thus:

     #baseRoom "Lobby"

     There is no default for this parameter.

     ------
     #MainFloor
        MainFloor is analogous to #baseRoom.  Any Citadel-86 V3 has a base
     floor, just as it has an Aide> room, etc.  This parameter allows you to
     name this base floor.  This parameter is a string value which cannot be
     longer than 19 characters, and specifies the name of your base floor.  So,
     if you want to name your base floor MAIN FLOOR, you'd have

     #MainFloor "MAIN FLOOR"

     There is no default value for this parameter.

     ------
     #CRYPTSEED
        Citadel-86 automatically encrypts all sensitive data files.  While the
     algorithm used can, of course, be broken by the determined, particularly
     since the code is available for perusal, the encryption does provide
     protection against casual eyes, mistakes, and amateur system breakers.  We
     do encourage you to take precautions of your own, such as not opening
     directory rooms into sensitive data areas.

        CRYPTSEED is an encryption seed Citadel-86 uses to encrypt your
     data; if someone should acquire of all of your data files but for
     CtdlCnfg.Sys, then they still won't have access to your system until they
     figure out what your CRYPTSEED is.  DON'T EVER CHANGE THIS VALUE WHILE
     RUNNING A CITADEL-86, OR EVERYTHING WILL BECOME MESSED UP!




                                     -12-




        We do not know of any value you can select which will "deactivate"
     the encryption process (to be frank, we don't understand the encryption
     algorithm ourselves).  Pick a value at random; the value should be a
     value less than 65536.  Here's an example:

     #CRYPTSEED    69            -- a little hubris for the shy

     ------
     #UNLOGGED-WIDTH
        This parameter is used for users who have not logged in yet to specify
    the width of their screens.  If not present, it will default to 40.
    Remember this applies to your login banners.

    #UNLOGGED-WIDTH 79          - makes it all look normal


     Part 3 of Section 1: DATA FILE SIZES

    ------
     #MESSAGEK
        MESSAGEK defines how much disk space you wish to allocate for messages
     on your installation.  There is no way to define how many messages you
     want in your system, or how fast they turnover.  All the messages in your
     system will reside in CTDLMSG.SYS, and thus the number of messages in your
     system at any given moment will depend on the length of the messages being
     entered into the system by your users.  The turnover rate of your messages
     will depend on how busy your system is.  As an example, Test System has a
     611K message base, which holds 2100 messages +/- 300, of which some are of
     fairly good length.  Turnover seems to between 3 weeks and a month, since
     80-160 messages are entered a day.  However, Test System is also a busy
     system.

        The sysop of an installation should also keep in mind that very large
     systems, with many new messages, can be intimidating to new users, so
     large message spaces should be approached with caution.  Remember, there
     is a utility for expanding the message base, but not for shrinking it.

        This is a numerical value which you specify in 'K', which is actually
     1024 bytes/K.  So, for example, to specify a 250K message file

     #MESSAGEK 250               -- 250K message base

     ------
     #MSG-SLOTS
        This numerical parameter specifies how many messages per room will
     be used on this system (the lone exception is the Mail>, which is covered
     by the following parameter).  If you wanted to use Citadel-86's
     traditional number of messages per room, you'd have

     #MSG-SLOTS 58

     ------
     #MAIL-SLOTS
        This is a numerical parameter specifying how many messages per log
     record you wish to reserve for Mail.  The Mail> room is the only
     room in the system whose data is not kept in CTDLROOM.SYS.  Instead, the
     file CTDLLOG.SYS contains the "Mail>" room, reserving for each account




                                    -13-





     enough room for MAIL-SLOTS Mail messages.  Therefore, this parameter gives
     you the ability to decide the maximum number of Mail> messages per user
     they can access.  Please remember if a user gets more messages
     in Mail> than there are MAIL-SLOTS between two successive logins, then
     they will lose the earlier messages sent to them.  Another consideration
     is many users like to review old Mail when engaged in an in-depth
     private conversation.  Therefore, setting MAIL-SLOTS to a low value may
     not be the attractive alternative it first seems.  However, it should
     go without saying a high MAIL-SLOTS value may eat up more room than
     necessary on your drives.  The section on LOGSIZE will give an exact
     formula for how much space your log will take up.  If you wanted to use
     what Citadel-86 used before V3, you'd have

     #MAIL-SLOTS 58

     ------
     #MAXROOMS
        This numerical parameter specifies the maximum number of rooms your
     system will support.  Since the baseRoom, Aide>, and Mail> room are
     necessary, the smallest value you can give is 3.  The largest number is
     65536 (probably).  If you wanted to have a 64 room system, you'd have

     #MAXROOMS 64

        You can use the following formula to estimate the number of bytes a
     room file will take up on your system:

          # of bytes = MAXROOMS *(50 + (6 * MSG-SLOTS))

     ------
     #LOGSIZE
        This numerical parameter gives you the ability to decide
     how many accounts will be available on your system.  If you run a system
     in which more accounts are used than there are accounts reserved, then new
     accounts are generated by killing old accounts.  Accounts are recycled
     by finding the account who's last use is the oldest of all the accounts
     in the system, under the assumption such an account is no longer active.

        All space is reserved immediately for these accounts.  The size of
     this file can be estimated from the formula

          # of bytes = LOGSIZE * (82 + MAXROOMS + (6 * MAIL-SLOTS))

     so if you are operating in a restricted environment, plan accordingly.

        If you need to, you can expand the size of the log through the use of
     the DATACHNG utility, but the log cannot be shrunk.  This is a numerical
     value.  Here is an example:

     #LOGSIZE 180                -- Usually adequate.

     Part 4 of Section 1: DATA FILE LOCATIONS

        Now we discuss where you want the data files to be located on your
     system.  These parameters are all specified in the same way, as a string
     value (which does not obey formatting directives, naturally) telling
     Citadel where on your system the given data file or files associated with
     the given parameter is located.


                                    -14-






        Simply use the MSDOS relative directory specification.  You can
     ONLY specify a subdirectories of the current directory on the disk you
     specify (if you don't specify a disk, then the current disk will be
     assumed).  So, some sample valid specifications would be "c:", "a:system",
     "b:msgs", and "i:bark".  Some sample INVALID specifications include
     "c:\citadel\msgs" (an absolute specification, rather than relative),
     "a:\audit" (ditto), and "i:.." (".." is technically not a subdirectory,
     but a parent directory).

        If CONFG.EXE cannot find the directory you specify, it will
     attempt to create the directory, after asking permission.

     ------
     HELPAREA
        This parameter specifies where all of your Help files will be located.
     These files are *.HLP, *.BLB, and *.MNU.  Normally, you should create this
     directory and place the help files in the directory before bringing up
     Citadel-86, since help files are usually online at all times.

     #HELPAREA "c:helps"         -- helps subdirectory on drive C:

     ------
     LOGAREA
        This parameter specifies the location of your CTDLLOG.SYS file (this
     file is sized by your LOGSIZE parameter).

     #LOGAREA "c:system"         -- put it in a general system dir

     ------
     ROOMAREA
        This parameter specifies the location of CTDLROOM.SYS, CTDLARCH.SYS,
     and CTDLDIR.SYS.

     #ROOMAREA "system"          -- another general system dir

     ------
     MSGAREA
        This parameter specifies the location of CTDLMSG.SYS.

     #MSGAREA "c:msg"            -- give msgs there own place in the sun

     ------
     FLOORAREA
        This parameter specifies the location of CTDLFLR.SYS.

     #FLOORAREA "floors"

     Part 5 of Section 1: POLICY OPTIONS

        Now we enter the POLICY part of the CtdlCnfg.Sys file.  The parameters
     discussed here represent the parts of your policy enforceable via
     the Citadel-86 software.







                                    -15-






     ------
     #AIDESEEALL
        This parameter is a toggle giving you some power over the scope of
     your aides' "vision".  If you set this parameter to 1, then your aides
     have access to all public AND private rooms (but not invite rooms, unless
     the have been invited).  If this parameter is set to 0, then aides only
     have access to public rooms, plus those private and invite rooms
     they've been invited to.  So, if you want your aides to see all public and
     private rooms, you would have

     #AIDESEEALL 1               -- See all but invite rooms

     if you don't want your aides to be so nosy, then you'd have

     #AIDESEEALL 0               -- See only public rooms.

     ------
     #LOGINOK
        The LOGINOK parameter controls whether your system is an "open" or
     "closed" system.  If you set LOGINOK to 1, the system will allow anyone to
     log in as a "new" user; i.e., it will ask a caller who uses an
     unrecognized password if they wish to login as a new user.  If LOGINOK is
     set to 0, the system will simply tell the caller without a valid password
     there is no record of their password, and they should leave Mail> to the
     sysop (but see OPER3.MAN's section on the various Help Files for another
     option); the only way to enter new users into the system is from the
     system console. If you want an open system, for example, you would have:

     #LOGINOK 1                  -- let the riff-raff in!

     ------
     #ENTEROK
        ENTEROK controls whether a caller who is not logged in can enter
     messages or not.  If ENTEROK is 1, then a caller who has not logged in
     can enter messages; if it is 0, then they must log in first, except for
     Mail to the sysop.  Setting ENTEROK to 0 can reduce vandalism; setting
     it to 1 gives your callers the privilege of anonymity.

     #ENTEROK  0                 -- log in first, folks!

     ------
     #READOK
        READOK controls whether an unlogged caller can read messages.  If
     READOK is 1, then they may.  If READOK is 0, then an unlogged caller can
     only read the policy statement available in the Mail> room (POLICY.HLP),
     and the help files.  Setting READOK to 0 can discourage unwelcome callers
     from using scarce system time.

     #READOK 0                   -- gotta login to read these gems...










                                    -16-



     ------
     #ROOMOK
        ROOMOK controls who can create new rooms on your system.  If ROOMOK is
     1, then any logged in user of the system may create new rooms.  If ROOMOK
     is 0, then only aides may create new rooms on your system.

     #ROOMOK 1                   -- a liberal policy

     ------
     #ALLMAIL
        ALLMAIL controls who can use the Mail> room.  If ALLMAIL is 1, then
     any user may use Mail> to send private messages to any other user on the
     system.  If ALLMAIL is 0, then only Aides may use the Mail> room in a
     general manner; regular folk can only use Mail> for messages to Sysop.
     Setting ALLMAIL to 0 may be appropriate on tightly focused systems
     operating in a small environment.

     #ALLMAIL 1                  -- the normal policy

     ------
     #DoorPrivs
        DoorPrivs lets you decide if new users should automatically be given
     door privileges or if they should ask you for them.

     #DoorPrivs 1               -- they get them automatically

     #DoorPrivs 0               -- they have to ask.

     ------
     #ANON-MAIL-LENGTH
        When this numeric parameter is present, all anonymous Mail> to sysop is
     limited to the specified number of characters.  When a message is sent
     exceeding this limit, the user loses carrier and the message is appended
     to a file named ANONMAIL, just in case the Mail was valid.  This option
     is useful when a vandal is attempting to scroll the message base and is
     being very persistent, to the point where even closing open logins just
     causes him to leave anonymous Mail to sysop, since that's the last
     vulnerable point in the system once login access is lost.  This would let
     you let limit anonymous Mail> to 300 characters.

     #ANON-MAIL-LENGTH 300

     If this parameter is not present or the value is 0 then there is no
     limit on anonymous Mail.

     ------
     #LOGIN-ATTEMPTS
     This parameter lets you control how many unsuccessful attempts an
     unlogged user can indulge in before the system will drop carrier on them.
     For instance, the following lets a user try four times before carrier is
     dropped.

     #LOGIN-ATTEMPTS    4









                                    -17-




     ------
     #FILE-PRIV-DEFAULT
     File privileges may be set for new users en masse.  #FILE-PRIV-DEFAULT,
     a numeric parameter, lets you set whether the average new user can have
     file privileges.  Use 1 to indicate they may, 0 to indicate they may not.

     #FILE-PRIV-DEFAULT  1

     means you're a generous soul.  If this parameter is not present, it will
     default to 1 (on).  You may also assign file privileges individually
     using LOGEDIT or the <U>ser Administration menu hanging off of the Sysop
     Menu.

     File privileges do not apply to uploads.

     ------
     Part 6 of Section 1: MODEM HANDLING
        We now enter into defining the essential details of your communications
     hardware.

     ------
     #IBM
        You use this parameter to tell your Citadel-86 if your system is
     running on an IBM PC/XT/AT or compatible, or if it is running on a Zenith
     Z-100 (set it at 0). If you have an IBM, you'd have

     #IBM 1                      -- Big Boo

     ------
     #COM
        This parameter is meaningful only for IBMs, and selects which COM port
     the modem is attached to (on Z-100s only J2 ports are supported).  For
     IBMs, only COM ports 1, 2, 3, and 4 are supported.

     #COM 1                      -- If you are using COM1.

     ------
     #SYSBAUD
        The SYSBAUD parameter is used to tell Citadel-86 what baud rates your
     hardware will support.  Citadel-86 cannot normally be configured to run
     high baud rates while excluding lower baud rates (i.e., operate
     correctly at 1200 baud but not at 300 baud).  Here's the mapping:

       0 => 300
       1 => 300/1200
       2 => 300/1200/2400
       3 => 3/12/24/48
       4 => 3/12/24/48/96
       5 => 3/12/24/48/96/14.4
       6 => 3/12/24/48/96/14.4/19.2

     #SYSBAUD 1                  -- A 3/12 system.









                                    -18-




     ------
     #modemSetup
        This parameter is used to initialize your modem.  It is a string value
     parameter obeying the formatting directives; however, you should be
     warned Citadel-86 automatically appends a "\r" to the end of this
     string before sending it to the modem.

        And when is modemSetup sent to the modem?  It is automatically sent
     while Citadel-86 is initializing, and it will also be automatically
     sent to the modem whenever the <R>einitialize command is selected from the
     Sysop Menu (i.e. privileged function:).

        The value you use for this string should cause the modem to be
     put into a mode where it will function suitably with Citadel-86.  This
     includes auto-answer and response to DTR, at the very least.  Other
     options you may wish to consider include turning the modem speaker
     off (if you have one); consult your modem manual for details.  The example
     we have here is biased towards Hayes/compatible modems.  You may have to
     do some research if you're using an odd modem.  Our example turns
     auto-answer on and turns off the speaker on a Hayes modem; note the lack
     of "\r".

     #modemSetup "AT S0=1 M0"           -- Surely an exercise in aesthetics...

     ------
     #REINIT
        As faster and faster modems appear on the scene, some of these modems
     are displaying odd characteristics which did not appear in the early
     300/1200 modems.  Chief amongst these is that some modems, after
     accepting a call at a baud rate lower than the modem's highest, will not
     accept calls at higher baud rates without being reinitialized at the
     highest baud rate.  If your modem is one of these types, then you will
     wish to use this parameter.

        Also, we have observed that some modems, although capable of accepting
     calls at high baud rates directly after low baud calls have been
     accepted, are not as reliable in the area of Result Codes as we might
     like.  Since Citadel-86 can use Result Codes (see Section II.9.d), we
     would like to see this improved, and, fortunately enough, we have
     observed using #REINIT with such modems actually increases their
     reliability.  So, even if you have a good modem, you may wish to use this
     parameter.

        When this parameter is present, it causes Citadel-86 to reinitialize
     the modem at its highest rate with the string you specify in this
     parameter.  This parameter accepts format directives.  For most Hayes
     compatible modems, the string "AT" is usually more than acceptable.

     -#REINIT "AT"                      -- disabled, but recommended value












                                    -19-




     ------
     #DISABLE-MODEM
     #ENABLE-MODEM
        Usually, when Citadel-86 needs to "disable" your modem (that is,
     cause it not to answer the modem), it "drops" the DTR pin (electrical
     stuff, don't worry about it), which usually causes the modem to stop
     answering the phone.  The modem is disabled whenever you, the sysop,
     uses the system at the system console.

         Some sysops, however, would prefer the modem go "off-hook"; that is,
     the modem should hold your phone line open and thus cause a busy signal
     for all callers while you're on.  These optional string parameters,
     when present, are sent to the modem when disabling and enabling the
     modem, thus making it easy to force a busy signal when you're on if
     you know what command to send to your modem.  For example, "ATH1" will
     put most Hayes-type modems "off-hook", and "ATH0" will put them back
     on-hook.  In the following, we've disabled the parameters since we don't
     particularly recommend the use of these parameters ourselves, but the
     values are what we'd probably recommend if we used them.  Note the use
     of "\r" at the end of each!  Citadel-86 will not! automatically append
     the carriage return needed to force the modem to process the command, so
     you must do that yourself!

     -#DISABLE-MODEM "ATH1\r"
     -#ENABLE-MODEM  "ATH0\r"

     ------
     #LOCK-PORT
        This advanced parameter is used for "locking" your com port at the
     baud rate you specify.  This parameter is primarily useful when you
     are using a USR high speed modem (HST, Dual-Standard, etc.) and you want
     to have the callers, when they are calling in with compatible modems, to
     enjoy the highest possible throughput, which is achieved by having the
     modem talk to the computer at a specific (and high) baud rate, regardless
     of what the caller is connected at.

        As we said, this is an advanced option.  If you plan to use it, you
     must make sure your modem knows about it and is fed the correct modem
     commands so it knows what baud rate it should talk at.  You should use
     the #REINIT parameter to tell it this information.

        The parameter you specify to #LOCK-PORT should be a number indicating
     what speed you want the computer to talk to the modem.  Use the same
     scheme as for #SYSBAUD, i.e., 300 = 0, ... 4 = 9600, 5 = 14400, and
     6 = 19200.  For example, if you have a good enough serial port to handle
     19,200 baud with your USR modem, you would want

     #LOCK-PORT 6

     in your CtdlCnfg.sys.











                                    -20-




     ------
     Part 7 of Section 1: VIDEO OPTIONS
     ------
     OLDVIDEO
        This parameter is difficult to categorize, so we'll just lay the cards
     out on the table.  Basically, every once in a long while we run across
     some computer that hangs when Citadel-86 is run, and it has something to
     do with the video portion of Citadel-86.  (We haven't actually seen this
     happen in quite a while, but ...)  Therefore, if you place #OLDVIDEO in
     CtdlCnfg.Sys, Citadel-86 will use its old video routines for display,
     rather than the new.

     -#OLDVIDEO         -- disabled

     ------
     FOREGROUND
     BACKGROUND
     STATUS-FOREGROUND
     STATUS-BACKGROUND
        These four parameters allow you to specify what colors will show up at
     the system console.

     FOREGROUND specifies the color of the characters themselves, except on
     the status bar.

     BACKGROUND specifies the background of the screen, except on the status
     bar.

     STATUS-FOREGROUND specifies the color of the characters of the status
     bar.

     STATUS-BACKGROUND specifies the background color of the status bar.

        You have the following colors to select from.  This first list of
     colors may only be used as FOREGROUND selections:

        DARK GRAY, LIGHT BLUE, LIGHT GREEN, LIGHT CYAN, LIGHT RED, LIGHT
        MAGENTA, YELLOW, WHITE.

        This second list of colors may be used as either FOREGROUND or as
     BACKGROUND selections:

        BLACK, BLUE, GREEN, CYAN, RED, MAGENTA, BROWN, LIGHT GRAY.

        Please note on some color monitors not all colors are
     available, and on monochrome monitors you should probably select
     highly contrasting colors for Foreground/Background pairs.  Here is an
     example:

     #FOREGROUND RED
     #BACKGROUND BLUE
     #STATUS-FOREGROUND LIGHT GREEN
     #STATUS-BACKGROUND BLACK

        Also note Citadel-86 is accompanied by a utility program named
     SCREEN.EXE which will help you select colors easily.  Please see the
     Utilities manual when you are ready to play with your screen colors.
     The EASE utility is also capable of helping you select screen colors;
     in fact, SCREEN is classed as an optional utility, and you may not have
     it.

                                    -21-




     ------
     CLOCK
        The status bar of Citadel-86 contains a clock, updated every minute,
     in the far right-hand corner.  Some folk may not want this clock,
     however, while others only want to see the clock only when a user is on
     the system.  Therefore, the parameter #CLOCK is available to control the
     behavior of the status bar clock.  The value you place after #CLOCK
     controls the behavior of the status line clock.  Here are the supported
     values:

     o "None" - If this is present, then you never have a status bar clock.
     o "Inuse" - If this is present, the clock is only displayed when the
                 system is active.
     o "Always" - This causes the clock to be active all the time.

        So, for instance, if you want the clock to never be on display,

     #CLOCK None                - No clock

     would do the trick for you.  If this parameter is not in your
     CtdlCnfg.Sys, "Always" is considered the preferred value.

     ------
        If you are a novice setting up Citadel-86 for the first time, please
     SKIP to Section II.7.  This is the end of Section 1 of CtdlCnfg.Sys,
     parameters which must be set for Citadel-86 to run correctly.  The other
     three sections of a virgin copy of CtdlCnfg.Sys (which we assume you are
     working with) have been given default values that shouldn't cause any
     problems with running a Citadel-86.

        If, on the other hand, you're just exploring what's available, continue
     on your merry way!

     II.6.c Section 2 of CtdlCnfg.Sys

        Now we enter into the realm of options which may prove useful to you in
     your particular environment, but which are not necessary for the correct
     operation of a Citadel-86.  We're going to begin by discussing a general
     time-driven event-handler facility.  Then we'll talk about some other
     miscellaneous parameters.

     ------
     #event ...
        This is what we're calling a "time-driven event-handler", which we're
     going to define as the ability to cause Citadel-86 to do certain things
     at times you specify.  So, for instance, you can have the system
     come down at certain times of the day to back itself up, or have it go
     into networking mode several times a week -- or several times a day.  Or
     do whatever your imagination suggests.  Any number of these #event
     parameters may appear in your CtdlCnfg.Sys file.

        This is the generic format of these parameters.

     #event <days> <time> <class> <type> <duration> <warning string> <depends>







                                    -22-




        Here is an explanation of each parameter field in the above.

     <days> can be any of the values "Mon", "Tue", "Wed", "Thu", "Fri", "Sat",
     "Sun", or "All", or any combination of the first seven.  If used in
     combination, separate each with a ',', but NO spaces are allowed.  This
     part of #event is used to specify on what days this event is to take
     place.  So, if you want something to happen only on Wednesdays and
     Saturdays, then you'd have

     #event Wed,Sat ....

     The 'All' value means, of course, all days of the week.

     <time> is the military specification of what time of day this event is
     supposed to happen (unless the class of this event is 'relative' -- see
     below).  For instance, 11 AM would be

     #event .... 11:00 ....

     while 11 PM would be

     #event .... 23:00 ....

     and 12:30 AM would be

     #event .... 00:30 ....

     Only one time can be specified in this field.  If you need the same event
     to happen at multiple times, then use separate #event entries.

     <class> indicates the class of the event, which is roughly what kind of
     event it will be.  C-86 supports twelve classes of events at this time,
     as described below.

     'network' -- this indicates Citadel-86 should drop into networking
     mode on the day(s) at the time indicated by the <days> and <time> fields.
     See NETWORK3.MAN for more information.

     'until-done-net' - This class of event is very much akin to the 'network'
     class of event, and before using this event it is recommended the
     'network' class be reviewed.  This class differs in that if all systems
     on the member nets specified for this event are reached (or do not need
     to be called) then the system will immediately exit the network session.
     Spine systems will be called regardless of the need to connect.  The
     <depends> format for this class is the same as for 'network'.  See
     NETWORK3.MAN for more information.

     'external' -- this indicates Citadel-86 should come down on the
     day(s) at the time specified by the <days> and <time> fields.  The
     ERRORLEVEL Citadel-86 should generate when it comes down will be
     discussed later in the subsection on the <depends> field.  This class
     should be used in conjunction with a carefully written batch file.

     'relative' -- this indicates Citadel-86 should come down X minutes
     after it has come up (this is used to replace the TIMEOUT and HOUROUT
     parameters of pre-V3 Citadel-86).





                                    -23-




     The number of minutes (X) should be expressed in the <time> field; the
     <days> field has no meaning (although it should be filled in) when class
     is 'relative'.  The ERRORLEVEL to be generated by Citadel-86 when it comes
     down will be discussed later, but for now we'll state it occupies the

     <depends> field.  For instance, if you want your system to come down 6
     hours after it comes up, do something, and then come back up (at which
     point you should realize it'll come back down again 6 hours after that,
     unless another event comes first), you would have an event like:

     #event Sat 6:00 relative .... 7

     in your CtdlCnfg.Sys (note Sat is meaningless, but some valid field
     has to be there), and your batch file would have something like this:

     :loop
     ctdl
     ...
     if ERRORLEVEL 7 goto doseven
     ...
     :doseven
     REM this is a generic program call, fill in with what you'd really do
     generic
     REM other things..
     ....
     REM now bring Citadel-86 back up
     goto loop
     ....

     'dl-time' -- This indicates a "download time limit" should be
     activated.  When this class of event is active, the total amount of time
     a user may use in downloads during the period of time this #event is active
     is limited by the value in the <depends> field, specified in MINUTES.
     This class value should only be used with the 'quiet' type (see below).
     When this event ends, download time limits return to an unlimited status
     automatically.

     'anytime-net' -- This class is used to activate the Anytime-Netting
     Callout feature.  This feature is detailed in NETWORK3.MAN; basically,
     events of this class specify the period of time in which calling out
     to other systems specified in the <depends> field of the event for
     anytime network purposes is acceptable.  The start time specifies when
     the system may becomes eligible for calling out, and the <duration> field
     indicates how long this eligibility is to last.  You may also specify how
     long the system is to be idle before anytime netting is to be attempted,
     and how long such net sessions should last, using the #event parameter.
     NETWORK3.MAN contains the closest thing to a full discussion of this
     feature, and we strongly recommend you read Network3.Man before using
     this class of #event.  This class should only be used with the <type>
     value 'quiet' (see below).

     'door-limit' -- This class is used to place time limits on how long the
     current user may spend using doors on your installation.  The <days>,
     <time>, and <duration> (see below) fields are the same as for most other
     classes, meaning you can designate which ever days and times you want
     doors to be limited, and for how long.  The <class> field should, of
     course, contain 'door-limit" as its value.  The only valid <type> value




                                    -24-




     (see below) for this class of event is 'quiet'.  This #event is ignored
     when the user is a sysop, either remote or at the sysConsole.  This
     #event is overridden by automatic doors (see below).

     'autodoor' -- This class is used to set up 'automatic doors' to be
     triggered when specified users log in.  The days, time, and duration
     fields are the same as usual, thus allowing you to deactivate and
     activate it at scheduled times.  See the <depends> definition below for
     the format of <depends> in connection with this class.  The only valid
     type value is 'quiet'.

     'chat-on' -- This class is used to enable Chat Mode (that is, allow
     users to signal the sysop for a chat) at a specified time.  Days and
     time are the same as usual.  However, the duration field does NOT
     imply that at the end of the event Chat will be automatically turned
     off.  However, by setting the duration field appropriately you may
     ensure Chat is turned on in case your system is brought up after the
     event but during a time you'd prefer chat to be on.  For example, if
     you wanted Chat to be on starting at 7PM, and were sure you wanted it
     on until 10PM, you might have a #event that looked like this:

        #event all 19:00 chat-on ... 180 ...

     This would not only turn Chat on at 7PM, but, if your system was down
     due to a power shortage (for example) until after 7PM and then brought
     up, the duration of 180 minutes would still turn Chat on.  If you had
     used 0, then Chat would not have been turned on if your system was down
     at 7PM.  This class should only be used with the <type> value 'quiet'
     (see below).

     'chat-off' -- This class is the same as 'chat-on' except, of course,
     chat is turned off at the specified time.

     'redirect' -- This class lets you redirect an incoming file from the net
     to a specific directory, which can be useful for automatic network
     domain map updates and the like.  The only valid <type> field value for
     this class is 'quiet.'  The <depends> field will contain, in order, the
     name of the incoming file to trigger on, the directory to place the
     file in, and the system from which this will be accepted (other systems
     sending same-named files will only result in the file being put in the
     normal file reception area, as will files from rogues if you are using
     network passwords).

     'newusers-allowed' -- This class is strongly analogous to the chat-on
     class.  At the specified time on the specified days, new users will be
     allowed to create their own accounts, regardless of the value of the
     #LOGINOK parameter in your CtdlCnfg.sys file.  As with the chat-on class,
     the duration field of the event should be set to cover the entire time
     new users will have this privilege, in case your system is brought up
     sometime during that time period.  Additionally, at the end of this event
     the parameter will NOT be set back to its old value; instead, it is left
     on.  If you want to disable the privilege when events of this class expire,
     see the next class.  Events of this class should always be of type 'quiet.'
     This class has no <depends> field.







                                  -25-



     'newusers-disallowed' -- This class complements 'newusers-allowed' and
     should be used to disallow new users from creating their own accounts.
     Example: to let new users create accounts at 7pm to 12pm and turn that
     ability off at all other times, use the following two lines:

#event All 19:00 newusers-allowed quiet 300 ""
#event All 00:00 newusers-disallowed quiet 300 ""

     <type> defines what type of event this will be, which essentially means
     how Citadel-86 reacts when the event time comes around.  There are three
     types of events supported at this time: preempt, non-preempt, and quiet.

     'preempt' -- this indicates when it's time for this event to occur
     the current user (if one is on) will be kicked off the system.  A warning
     will be issued to the user 5 minutes before the event is to occur (or if
     they call in after the 5 minute mark has passed, they will get the warning
     immediately). This type should be used for events which MUST occur at a
     given time, such as networking.

     'non-preempt' -- this indicates the system is willing to wait until
     the current user is off the system before executing the current event.  If
     the time of the event is passed by, the event will still be executed when
     the caller logs off.

     'quiet' -- this indicates the event should occur with no notice given
     to the user.  Currently, this only makes sense with the 'dl-time',
     'door-limit', 'autodoor', 'anytime-net', 'chat-on', and 'chat-off'
     class values.

     <duration> defines how long the event will last, in minutes.  If duration
     is 0, then if you happen to bring the system up at the exact time the
     event is to take place, the event WON'T take place; for all other values
     of duration, the event will take place. Duration should probably be 0 for
     external events you only want to happen once, happen quickly, and
     bring the system right back up, such as a backup event in which your BAT
     file backs up the system and then brings it back up.  This can go so fast
     your system will be back up in less than 1 minute, so you don't* want
     duration set to 1 -- you want it at 0, otherwise the event could be
     executed more than once.  However, for network events you certainly want
     it set correctly.  A 45 minute network event would look like this:

     #event ... ... network preempt 45 ....

     <warning string> is only valid for 'preempt' and 'dl-time' events.  It
     is sent to the user for the warning and for the "you've been kicked off"
     messages.  It should be enclosed in quotes.  Here's what the messages
     look like for preemptive events:

     "<beep>WARNING: System going down at <time> for <warning string>."

     "<beep>Going to <warning string>, bye!"

     So, for networking,

     #event .... "networking" ...

     works just fine.  The message, when used for download time limit events,
     looks like this:




                                  -26-




     "I'm sorry, that would exceed the current cumulative
               download time limit of <warning string>."


     <depends> is a parameter whose meaning depends on the class of the event.
     If the class of the event is 'external' or 'relative', then this value is
     the ERRORLEVEL Citadel-86 is supposed to generate as it comes down,
     and should be used in BAT files for further processing.  The upper
     effective limit on this parameter is whatever MSDOS allows in BAT files,
     we think.  Before leaping into this, however, please review the section
     on BAT files in this Installation Manual, paying particular attention to
     already-reserved ERRORLEVELS.

     If the class of this event is 'network', then <depends> specifies which
     net(s) this network event is going to participate in.  While we are not
     going to discuss in detail what Citadel-86's "multinet" capability is
     right now, here is a summary: Citadel-86 supports handling multiple
     C86Nets.  Each network is identified by a number; all of the nodes in
     your system can be associated with 0 or more of these nets. Thus, using
     the <depends> field can allow you to network with certain systems at one
     time and/or day, and other systems on other times and/or days. The
     <depends> field must have at least one of the nets identified here, and
     may have more if a particular network session is servicing more than one
     network at a time.  If more than one net is to be serviced, place a comma,
     and ONLY a comma, between each net identifier. So, if you wanted to
     specify nets 1, 6, and 14, you'd have

     #event .... 1,6,14

        If the class of the event is 'dl-time', then the depends field specifies
     the maximum number of minutes which may be spent in downloading while
     this event is in effect.

        If the class of this event is 'anytime-net', then depends consists of
     three values: <dead time> <session length> <member net list>.  Dead time
     is how long the system is to be idle before attempting netting, session
     length is how long such net sessions should last, and member net list is
     just like the normal network session member list.

        If the class of the event is 'autodoor', then the format of the
     depends field is

        "username" doorentrycode

     The reason for the quotes around the username is some users have
     multi-word names.  doorentrycode is the entry code for the #door to be
     triggered when user "username" logs in.

        If the class of the event is 'door-limit', then the depends field
     specifies the time limit on doors in minutes.

        If the class of the event is 'chat-on' or 'chat-off' then there are
     no values for the depends field.

        if the class is 'redirect' then the <depends> field will contain
     <filename> <directory name> <system name>, for the name of the file
     which will be redirected, the directory to put it in, and the system from
     which the file will be accepted and redirected (same-named files from
     other systems will be placed in the normal area, #FILE_RECEPT_AREA).


                                  -27-




        And that's it for the #event parameter(s).  We hope our explanation
     is understandable; we sure had a hard enough time writing it!  Oh, and
     there are examples of real-world #event entries in Section XIX (we think)
     of the Operations Manual.

     ------
     #sysPassword
        This parameter gives you access to the Remote Sysop capabilities of
     Citadel-86.

        A "Remote Sysop" is an Aide, not at the System Console, who knows
     the Remote Sysop Password.  A Remote Sysop's capabilities include complete
     access to the Sysop Menu (yes, including such silly things as changing
     the Baud Rate -- See OPER3.MAN) and when editing rooms the Remote Sysop
     can do what a normal Sysop can do.  A Remote Sysop gains access to the
     Sysop capabilities in exactly the same way as a normal Sysop does, by
     sending a ^L to the system -- but a Remote Sysop has to supply a password.

        This parameter, a string value which does not obey formatting
     directives, does NOT (repeat NOT!) specify the Remote Sysop Password.
     Rather, it specifies the NAME of a file containing, on one line, the
     Remote Sysop Password (this allows you to hide your Remote Sysop Password
     somewhere on your system).  This filename may specify any file anywhere
     on your system, including different drives and subdirectories.

        The password itself must be at least 15 letters long, and is, unlike
     most passwords, case-sensitive.  WARNING: If you change the password
     in the file, you must run CONFG again (CONFG ONLYPARAMS -- see the Section
     on Command Line parameters).

        If this parameter is not specified, or the file is not found, then the
     Remote Sysop facility is not active.

        We really don't recommend you use this facility, due to the abuse
     possible if some juvenile delinquent breaks two passwords.  However, if
     you insist on using this facility, and placed your password in a file in
     a directory on drive G, in a file named PWD in a directory on the root
     called HIDING, you'd have the following in your CtdlCnfg.Sys file.

     #sysPassword "g:\hiding\pwd"       -- Note the lack of '\\' sequences

     ------
     #door ...
        This parameter is used to make a door available to the user.  This
     subject is treated fully in Section XI of the Citadel-86 Operator's
     Manual (OPER3.MAN).

     ------
     #ISDOOR
        This parameter allows you to run Citadel-86 as a door itself.  When
     you configure a Citadel-86 using this parameter, it will no longer
     attempt to initialize the modem when coming up, because it will expect a
     user to be there already.  For further details, see the Operations Manual
     Section XII.

     ------
     #AUDITAREA
        This parameter is just like the MSGAREA, et al.  It is a string value
     parameter specifying a drive and directory which will hold three audit
     files.  If this parameter is not present in your CtdlCnfg.Sys file, then

                                    -28-





     the audit files will not be created or updated by Citadel-86.

        The audit files are known as CALLLOG.SYS, DOORUSE.SYS, and FILELOG.SYS.
     They are simple ASCII text files containing notes regarding system usage.

        CALLLOG.SYS contains three types of notes.  The first type lists when
     the system has come up and down.

        The second type records who has called, listing login and logout times,
     one line per person, in the following format:

     <person>   :   <login time> - <logout time> <baud rate>

        Occasionally such a line will have an extra character appended onto it,
     and they have the following significance.

        '+'  The user logged in as new.
        '-'  The user used .TS to logout.
        'T'  The user timed out on the system.
        'E'  The user hit the error limit on the system and was
             kicked off.
        'B'  The system kicked the user off for too many offenses against
             BADWORDS.SYS.
        'C'  The user tried to chat with you.

        The third type of message in CALLLOG.SYS are notes regarding network
     sessions, both normal and anytime-net.  These record on a single line
     the start and end times of the net sessions.  This particular message can
     be disabled by using the #CLEAN-CALLLOG parameter.

        FILELOG.SYS format is somewhat different.  Generically, it looks like
     this:

     <user name> @ <baud rate>
        file1 (n bytes) <roomname> <U or D> <start to end> <length> <protocol>
                                                                        [FAILED]
        file2 (n bytes) <roomname> <U or D> <start to end> <length> <protocol>
                                                                        [FAILED]
        ...

        This format keeps the number of user names down.  "n bytes" is the size
     of the file.  "roomname" is the room involved.  "U or D" refers to whether
     the named file was Uploaded or Downloaded.  "start to end" refers to start
     time and end time of the file session, while length is the amount of time
     involved.  Protocol will be one of the three XMODEM, YMODEM, or WXMODEM.
     "FAILED" will only appear on the line if the transfer failed.

        DOORUSE.SYS simply lists who used what doors for what amount of time
     at what time of the day.

        If you want to have a call log, you would have something like this in
     your CtdlCnfg.Sys file:

     #AUDITAREA "c:audit"         -- This can only be a subdirectory






                                    -29-



     ------
     #MIRRORMSG
        The structure of Citadel-86's message base causes frequent disk access.
     While this is not particularly deleterious for a hard disk, this kind of
     activity has been known to actually destroy floppy drives. Therefore, it
     makes sense to put the message base into a RAM drive. However, this leaves
     systems vulnerable to message base loss due to power failure. Because of
     this, Citadel-86 has the ability to support two identical message bases at
     once.

        The first message base functions as the primary; messages are written
     to and read from this base. This message base is specified by the MSGAREA
     parameter.  The second message base, however, is subject only to writing,
     thus saving wear and tear on the media involved.  Since the primary
     message base (the one both written to and read from) is subject
     to a lot of wear and tear, this message base should be placed in a RAM
     disk. The MSGAREA parameter mentioned earlier specifies the area for the
     primary message base.  It is your responsibility to make sure a copy
     of CTDLMSG.SYS is in the RAM disk when you bring Citadel-86 up; Citadel-86
     will not do that for you.

        The secondary message base, since it is only written to, should reside
     on permanent media, such as a floppy.  The parameter MSG2AREA, a string
     value not responsive to formatting directives, specifies the area
     where the secondary message base should reside.  Since both message bases
     are written to simultaneously, they should remain identical.

        If you wish to use this option, MIRRORMSG should be set to 1;
     otherwise, it should be set to 0.  If MIRRORMSG is set to 1, then MSG2AREA
     should specify where the secondary message base should reside.  For
     instance

     #MIRRORMSG 1                -- yeah, why not?
     #MSG2AREA "b:msg"           -- on floppy, of course

     ------
     #HOLDAREA
        Citadel-86 has the optional capability to save messages inadvertently
     interrupted during composition for later completion.  The reason we say
     "optional" is the method used to save such messages is to save them as
     files on disk, and in a restricted environment such an ability may not be
     desirable. Thus, this feature is only available on systems in which
     #HOLDAREA is defined.  #HOLDAREA is another directory specification,
     exactly like those of Section 1 of CtdlCnfg.Sys.  All interrupted messages
     will be stored there until the next time the user logs in.  These files
     are currently about 8K bytes long.

     #HOLDAREA "hold"

     ------
     #sysopName
        This parameter is used to tell your system who the sysop is.  The only
     real effect of this parameter is all Mail> to sysop is automatically
     routed to the account that you specify in this parameter's string value.
     (This will also affect net Mail> to sysop.)  If you're not using this
     parameter, or the account does not exist, then Mail> to sysop will end up
     in the Aide> room.

     #sysopName "Me!"



                                    -30-





     ------
     #SYSOP-ARCHIVE
        This optional string parameter is used to tell your system where to
     archive the system operator's Mail.  The string specifies which file the
     Mail> should be archived to.  If the parameter #sysopName is not specified
     or if this parameter is not specified then Sysop Mail will not be
     archived.

     #SYSOP-ARCHIVE "c:\citadel\moocow"

     ------
     #EDITOR
     #EDIT-AREA
        These two parameters allow the sysop to specify a
     Sysop Editor for use at the System Console.  Full information on
     this feature is contained in OPER3.MAN Section X.  Essentially, the Sysop
     may use the editor of his/her choice for message composition when at the
     System Console, and these two parameters allow the System Operator to
     specify what editor to use and where to place the temporary file.

        #EDITOR is the name of the editor, along with any necessary options.
     It does not obey formatting directives.  If #EDITOR is not present in
     CtdlCnfg.Sys, then the Outside Editor is not available.

        #EDIT-AREA is entirely optional, and does not disable the Outside
     Editor if it is not present.  The System Operator may use this parameter
     to specify some area of his disk system for the placement of the
     temporary file containing the message text other than the current drive
     and directory (this is useful for RAM disks, etc.).

     #EDITOR "q"        -- qedit
     #EDIT-AREA "d:\"   -- in the root of drive D:

        See OPER3.MAN for full information.

     ------
     #CLEAN-CALLLOG
        If this parameter exists in your CtdlCnfg.Sys, then network sessions
     will not appear in your CALLLOG.SYS.

     ------
     #ANONYMOUS-SESSIONS
        If this parameter exists in your CtdlCnfg.Sys sessions in which remote
     callers fail to login to be recorded in CALLLOG.SYS (if auditing is
     enabled -- see #AUDITAREA).  Normally, user sessions in which the caller
     never successfully logs in are not recorded.  This option lets you
     override this behavior.  This override does NOT apply to anonymous uses
     of the sysConsole.












                                    -31-




     ------
     #CONSOLE-TIMEOUT
        The optional parameter #CONSOLE-TIMEOUT allows you to specify CONSOLE
     timeouts.  The value you give will be interpreted as the number of seconds
     the system is quiescent in CONSOLE mode before timing out (that is,
     return to MODEM mode).  If this parameter is not present in your
     CtdlCnfg.Sys, or if its value is -1, then Console Timeouts are disabled
     on your system.  Example:

     #CONSOLE-TIMEOUT 600

     The system will timeout after 10 minutes when in Console mode.

     ------
     #CONSOLE-DELAY
        This parameter is for use on hardware with very fast video display
     systems, such as fast AT class machines.  Such hardware can make it
     difficult for the sysop to use their own system at the sysConsole.  This
     parameter lets you tell Citadel-86 to delay x milliseconds after each
     character when the user is at the sysConsole.  For example, to tell the
     system to hesitate for two milliseconds after each character:

     #CONSOLE-DELAY 2    -- 2 millisecond delay after each character

     This option does not affect remote users at all.  Use this parameter
     only if you find you need it.  If it's not present then there is no delay,
     of course.

     II.6.d Section 3 of CtdlCnfg.Sys

        This section covers the parameters of CtdlCnfg.Sys concerning the
     Citadel-86 networker.  We have no intention of covering the network itself
     in this section; we tried to cover that in NETWORK3.MAN, and direct you
     to there if you're interested.

     ------
     #NETWORK
        This parameter controls whether or not you're in the network at all.
     Set it to 1, and you are.  If it is set to 0, then you are not (initial
     setting for our virgin copy).  If you are planning to participate in the
     network, then please be sure you understand the section on the
     #event parameter, because you use #events to tell your system when
     to communicate with other systems on the networks.

     #NETWORK 1                  -- This system participates.

     ------
     #nodeDomain
        This is the name of the domain your reside in.  You may only reside
     in one domain.  This domain string is sent with each net message
     originating on your system (mostly as a way to facilitate users finding
     out how to send net mail to your system) (assuming you are netting,
     otherwise this is meaningless), and will be displayed, generically, like
     this:

     <date> @<time> from <author> @<nodeName> <nodeDomain display>





                                    -32-





     The reason we say "nodeDomain display" is that it's possible for some
     systems to customize the display of the nodeDomains of the messages
     passing through.  Assuming they aren't customizing, an example of a
     display using the above and assuming the #nodeDomain is "wa" (or WA --
     this is case-insensitive) would look like this:

        82Nov23 from Cynbe ru Taren @ODD-DATA _ wa

     Here's what ODD-DATA's CtdlCnfg.Sys entry for #nodeDomain would then
     look like:

     #nodeDomain "wa"        -- just another string parameter

        See NETWORK3.MAN for more information on domains in Citadel-86.

     ------
     #DomainDisplay
        This optional string parameter, if present, effects how domain
     designations of messages from foreign systems are displayed on your
     system.  There is a special format to this string: somewhere within the
     quotes it must contain a "%s".  This "%s" will be replaced by the domain
     of the message.  For instance, if you wanted to override the default
     behavior of putting a " _ " between the node ID and it's domain with
     having the domain being placed between brackets, you'd put

     #DomainDisplay " [%s]"

     in your CtdlCnfg.Sys.  Notice the leading space.

     ------
     #RouteMail
        This parameter controls whether or not you categorically refuse to
     route network mail.  If you do choose to route mail, you can still
     control routing via individual flags for each node; see the RoutMail
     utility.

     #RouteMail  1              -- allows route mail to happen

     ------
     #MailHub
        This parameter lets you redirect mail which is domain oriented to
     another system which presumably has a better chance of delivering the
     Mail to the system in the domain you don't know much about.  See
     NETWORK3.MAN for far more detail than we provide here.  An example
     might be

     #MailHub "Data Drum"    -- current Illinois domain server

     ------
     #ServeDomain
        This parameter lets you decide if you want to be a domain-server.
     See NETWORK3.MAN for more detail.

     #ServeDomain "xx"






                                    -33-





     ------
     #NewNetPrivs
        This numerical parameter let's you decide if new users should
     automatically have net privileges or not.  If 1, then they do; 0, they
     don't.

     #NewNetPrivs 0                     -- let's be paranoid!

     ------
     #NETAREA
        This string parameter specifies where all the net files will be located
     on your system.  The "net files" are CTDLNET.SYS and various temporary
     files having the suffixes ML, RFL, VTX, and SFL, plus some files with
     numeric suffixes (like R3.0).  NETAREA is just like LOGAREA, MSGAREA,
     etc., specifying drivename, if necessary, and only a subdirectory of the
     current directory of the relevant drive.

     #NETAREA "netstuff"         -- let's put it in a directory called
                                 -- netstuff.

     ------
     #DOMAINAREA
        This string parameter specifies where all the domain files will be
     located.  See NETWORK3.MAN for more information on domains.

     #DOMAINAREA "domains"    -- make it a separate directory from NETAREA

     ------
     #SHARED-ROOMS
        This numeric parameter reserves room in each node record for the number
     of shared rooms you think you'd like to share.  Each takes up 6 bytes, so
     plan according in view of the number of nodes you'll have on your node
     list and the number of rooms you might want to share with other systems.
     If you want to change this value later, use a utility!

     #SHARED-ROOMS 4            -- conservative

     ------
     #NET_RECEPT_AREA
        This parameter specifies a directory on your system containing
     all files sent to your system by some other system during
     networking, using the Send File facility (this is not the same as
     requesting files over the network).  NET_RECEPT_AREA is a string value
     unresponsive to string formatting directives, of course, and it may
     specify any directory on your system, not just a subdirectory to your
     current directory.  So, supposing you wanted to specify
     C:\CITADEL\HOLDING as the directory for incoming files from the net,
     you'd have in your CtdlCnfg.Sys

     #NET_RECEPT_AREA "c:\CITADEL\HOLDING" -- directory

     ------
     #NET_AREA_SIZE
     #MAX_NET_FILE
        These two parameters allow you to control how much space you wish to
     devote to files coming into your system from the net via the Send File
     command (i.e., other systems sending you files without you asking).



                                    -34-





        NET_AREA_SIZE allows you to tell Citadel-86 how much space to devote to
     the directory specified in NET_RECEPT_AREA.  When a system attempts to
     send you a file, Citadel-86 will get the size of the file, and then check
     to see how much space is already being taken up by files in
     NET_RECEPT_AREA.  If the difference of NET_AREA_SIZE and the files already
     in NET_RECEPT_AREA is less than the size of the incoming file, then your
     system will not accept the file.

        MAX_NET_FILE allows you to control how big a file you will ever accept.
     If the size of the file being sent to you exceeds the value you specify
     here, then your system will not accept the file being sent.

        Both of these values are in terms of K.  So, for instance, if you only
     wanted to allow files of up 24K into your system, and only wished to
     devote up to 44K to NET_RECEPT_AREA, you'd have:

     #NET_AREA_SIZE 24
     #MAX_NET_FILE  44

     ------
     #callOutPrefix
     #callOutSuffix
        These two parameters control modem dialing during networking.  These
     are both string value parameters obeying formatting directives, and
     should be used to convey commands to the modem.  When dialing, Citadel-86
     constructs a phone number to send to the phone company, and sends the
     following to your modem:

      <callOutPrefix><phone#><callOutSuffix>

     callOutPrefix should alert the modem to dial, while callOutSuffix should
     do anything necessary to finish the dialing sequence (usually, just send
     a C/R to the modem).

        If you have a Hayes modem, we recommend you use the following values
     for these two parameters.

     #callOutPrefix "ATDT"            -- Tells a Hayes modem to dial out using
                                      -- touch tones
     #callOutSuffix "\r"              -- puts a carriage return at the end

        If you have a high speed modem, such as an USR HST, please see the
     next section for special variants of #callOutPrefix when you network
     with systems capable of the same high speeds.

     ------
     #DialOut300
     #DialOut1200
     #DialOut2400
     #DialOut4800
     #DialOut9600
     #DialOut14400
     #DialOut19200
        The new modems coming out today sometimes require different prefixes
     to dial and connect at different speeds.  For instance, the USR HST
     requires "AT&M0D..." for most dialing, but "AT&M4D..." to call USR HST
     modems at high speeds.  Therefore, Citadel-86 contains a flexible dialout



                                    -35-





     prefix scheme.  The above CtdlCnfg.Sys parameters are now available.
     They allow you to customize your dialing by letting you define special
     dial out prefixes for certain baud rates.  Those you don't define will be
     replaced by #callOutPrefix.  If you don't have a high speed modem requiring
     different dial out strings for different modem speeds, then you needn't
     worry about this section.

     ------
     #SCAN-NET-MESSAGES
        This CtdlCnfg.Sys parameter, if it's present, causes all incoming net
     messages to be scanned against BADWORDS.SYS.  Those which fail to meet your
     standard of decency are placed in the file DISCARD and a message will be
     left in your Aide> room.

     ------
     II.7 The Big Step -- Your first experience with CONFG
        You should have a complete, if only minimally, CtdlCnfg.Sys on your
     disk now (you DID save that file to disk when you were finished, didn't
     you?), so now it's time to process it into something CTDL.EXE finds
     palatable.

        You do this with CONFG.EXE.  First, make sure CtdlCnfg.Sys is
     located on your default disk; if you are running on a floppy-only system
     make sure you have the correct floppies in the drives.

        Run CONFG.  It will come up with some sort of identification banner,
     and then begin processing your CtdlCnfg.Sys.  Normally, it will echo each
     parameter as it processes it.  If it runs into a parameter it doesn't
     recognize, or a parameter value out of range, it will come to
     a stop and tell you about it (or at least it should).  Make note of the
     problem and edit your CtdlCnfg.Sys accordingly.  If it seems critical, or
     you don't understand what's wrong, review this manual, and if that
     doesn't help, some active research (local Citadel-86 sysops, etc.) may
     be called for.  (Good luck.)

        Once you get past this step, CONFG will grumble with the disk for a
     moment (or two on a floppy system), and then ask you some questions.
     This first set of questions depends on whether you created the system
     directories (assuming you specified some of the system files belong in
     their own directories) or not.  If you didn't, CONFG will ask you if it
     may create the directories needed for the system files; this gives you a
     chance to make sure you didn't screw something up.  If you didn't, then
     answer 'Y' (or 'y') for each question regarding directories.

        Once CONFG has decided the directories are setup correctly, it
     will try to open your system files (i.e., the message file, the log file,
     etc.), and since this is the first time you've run CONFG, it won't find
     them, and therefore it will complain about this, and tell you it is
     creating each of them.

        This is the first and last time you should ever have to see the
     questions about the directories, or the messages about missing system
     files.  If you do ever see them again, and don't know why, you may have
     problems.






                                    -36-





        Next, CONFG will ask if you wish to initialize your system files.
     Since this is the first time, answer 'Y'.  NEVER answer 'Y' again unless
     you know what you're doing, because answering 'Y' tells CONFG to ERASE all
     the data in your data files.

        Since you answered 'Y' (this doesn't happen when you answer 'N'),
     CONFG will ask if you wish to erase and initialize your message file
     (in case you didn't mean to say yes before).  Type 'Y', and then sit back
     and watch as CONFG creates the message base.  CONFG displays the number of
     'sectors' (128 byte chunks) to clear, and then counts them off as they are
     cleared.  If you are going to have a large (300K or more) message base
     and have fairly slow disk drive(s), this is probably the time to get that
     cup of coffee.

        Once it is finished with the message base, it'll ask if you wish to
     erase and initialize the room file, and then the log file.  Since you are
     still creating your system, answer 'Y' to them and watch as CONFG clears
     each file.

        If CONFG encounters any problems during this process, it will tell you
     about it and exit without finishing.  It's up to you to figure out what's
     wrong at this juncture.

        Once it finishes with these files, it tells you it is creating
     CTDLTABL.SYS (remember that file?), and exits after a few more seconds.

        You should now have a CTDLTABL.SYS on your current default disk, which
     also happens to be the disk your Helps reside on.


     II.8 CTDL -- That Childhood Experience
        And now we get to that long awaited moment.  DO IT.  Run CTDL, however
     you have to do it.  (Is your modem on?)

        If everything is put together right, you have enough memory, and
     everything is configured right, CTDL will be read in, grumble at your disk
     or disks for a moment, initialize your modem, rumble a little more,
     and then come up with YOUR welcome banner.

        If that's what happened, sit back!  Didn't it feel good?  Feel the
     warm, golden glow?  (Quick, knock on some wood.)  And now you should
     probably turn to OPER3.MAN, the everyday care and feeding of Citadel-86.
     The remainder of Section II covers advanced installation topics which you
     shouldn't concern yourself with right now, with the exception of Section
     II.8 which covers what to do in case of unexpected power losses and
     crashes. You should certainly read the advanced topics of Section II at
     some time in the future, because we talk about automating your
     installation with batch files, command line arguments, and other beasties;
     however, right now you're just getting used to being a Citadel-86 sysop.

        Delving into other topics when you're not familiar with the basic
     features of the sysop side of Citadel-86 could turn into a messy disaster
     neither you, nor we, would wish to deal with.  So turn to OPER3.MAN.







                                    -37-





        If CTDL DIDN'T come up, there are a large variety of reasons for the
     failure.  If your system seemed to make it up but came down relatively
     gracefully (i.e., left you at the system prompt), check your disks for a
     file named CRASH. It may give you (or the person you turn to for help!)
     a hint on what might be wrong. If it seems to think there's an error with
     a file, perhaps you forgot to configure MS-DOS correctly.  If CTDL itself
     complains about "no ctdltabl.sys!", then either the file isn't on your
     default disk when you called CTDL, or CONFG didn't successfully finish.

     II.9 When the inevitable happens
        Citadel-86, just like any other software, is not immune to such things
     as crashes, power failures, hardware failures, and the like.  When this
     happens, you must take corrective actions, because normally such
     occurrences will leave your system missing (or with a mangled version
     of) the valid version of CTDLTABL.SYS.

        In order to rebuild this vital file, you must run CONFG again.  CONFG
     will digest your CtdlCnfg.Sys, and then survey and summarize for CTDL the
     current contents of your data files.  Once it is finished, you may
     (usually) run CDTL.

        Let's go over exactly what will happen.  When you run CONFG, it should
     go through CtdlCnfg.Sys, just as it did in Section II.7, echoing each
     parameter as it encounters it.  Once finished, however, it's behavior will
     differ. It should not ask you if it may create the appropriate directories
     (since they should already exist), and it should not complain about not
     being able to find any of your system files (these should still exist,
     too!).  However, it WILL ask you if you wish to erase and initialize your
     system files.  This time reply N (with vigor!).  CONFG will immediately
     begin analyzing your data files, and after several minutes, depending on
     the size of your system, it will produce a CTDLTABL.SYS; your system will
     be fit to run again.

        Obviously, there are benefits to automating this process, particularly
     for handling power outages.  Consult the section on batch files and the
     section on command line options for details on effectively automating your
     system in such cases.


     II.10 Installation -- Advanced Topics
        By now you should have a pretty good feel for Citadel-86 procedures,
     but may wish to look into automating Citadel-86.  The first two
     subsections discuss subjects pertaining to that minor miracle; the third
     section will try to bring the first two together, with some representative
     examples of DOS BAT files.

     II.10.a Command Line options
        A 'command line option' is a string of letters you type directly
     following the program name.  Each command line option should be separated
     from the program name and any other command line option by at least one
     space.  Command line options are used to tell a program to do something it
     might not do if the option wasn't there.  In abstract, from drive C: of
     MS-DOS:







                                    -38-





     C><program name> <command line option 1> <c.l.o. 2> ...

        Both CONFG and CTDL have a set of command line options which you can
     use to make them do special things.  We'll treat each program separately.

     CONFG
        The CONFG program will respond to two options, which may appear
     together or individually on the command line.

        The first parameter is called ONLYPARAMS.  When CONFG finds this
     parameter on the command line, CONFG will NOT try to process your data
     files.  Instead, it will limit itself to reading and processing your
     CtdlCnfg.Sys file.  This ability is useful when you wish to change one of
     the CtdlCnfg.Sys parameter values without going through the entire
     process of reading your data files. You MUST have a completely valid
     CTDLTABL.SYS available for CONFG to read; otherwise, this option will be
     ignored and your data files will be processed.

        The second parameter is any string of letters not matching any
     other command line option for CONFG.  If this 'option' (you can just use
     some random string of characters) is on the command line, then CONFG will
     not ask whether or not you wish to erase and initialize your data files.
     Instead, CONFG will assume your answer was 'N' (i.e., you simply wish
     to perform a reconstruction).  Thus, CONFG will never query the keyboard
     for attention, and can run unattended, so long as all the data files are
     in their places.

     CTDL
        The CTDL program officially supports several options, and unofficially
     several more which may or may not be detailed here.  An 'official' option
     is an option we anticipate supporting for a while; an 'unofficial'
     option is an option used for experimentation, and will someday be moved
     into the CtdlCnfg.Sys parameter file (or just thrown away).

        The first command line option is called +netlog.  This option applies
     only to networking systems.  When employed, it will cause a log of all
     network sessions to be written to the file NETLOG.SYS in your NETAREA
     directory.

        +nochat completely shuts the Chat option off.  Normally, an aide can
     force a chat when Chat is turned off.  This command line option prohibits
     aides from forcing Chat when Chat is turned off.  This option does nothing
     when Chat mode is on.

        +vortex activates the Vortex Detection and Management feature.  For
     more information on this feature, see NETWORK3.MAN Section III.3.j.

        bps= is of use to those sysops using the #ISDOOR parameter.  See the
     Operations Manual Section XII for full details on the use of Citadel-86 as
     a door.

        +anon causes sessions in which remote callers fail to login to be
     recorded in CALLLOG.SYS (if auditing is enabled -- see #AUDITAREA).
     Normally, user sessions in which the caller never successfully logs in
     are not recorded.  This option lets you override this behavior.  This
     override does NOT apply to anonymous uses of the sysConsole.




                                    -39-




        +vandaloff disables the vandalism checking which occurs when an
     unlogged user sends Mail to sysop.  This checking consists of seeing if
     the message contains the same character occuring in a row more than
     8 times (e.g., "iiiiiiiii").  When this option is present, the checking
     is disabled.

    +nomeet disables the <M>eet User and .Enter Configuration Biography
     commands.  See OPER3.MAN for more information on these commands and why
     you might wish to disable them.

        +wx instructs Citadel-86 to attempt to use Wxmodem rather than
     Ymodem (or Xmodem) during its network transfers.  This option is not
     recommended.

        +noecho disables the screen echo (also accessible as the 'E' option on
     the Sysop Menu) when Citadel-86 comes up.  This is useful for systems
     with extremely slow video displays or systems operating in public.

        lddelay= lets the sysop decide how long Citadel-86 will wait for
     a connection on a long distance network call.  This defaults to 60
     seconds, and the value you place after the '=' should be specified in
     seconds.  For instance, "lddelay=120" would request a 2 minute delay.
     This is useful for calls to other continents.

        lowfree= allows the sysop to define a minimum free space left on
     disk.  If a user attempts to upload a file to a disk that doesn't
     have at least as much free space as specified in this parameter (units
     are K) then the upload is not allowed.

        paranoia= specifies the number of messages a user may leave in a
     room.  If the limit is exceeded then the user loses carrier.

    +conpwd indicates that the sysop password should be applied at the
     system console as well as to aides calling in from remote (although no
     one need be logged in at the system console).  This, in effect, makes the
     system console almost as secure as the remote side of Citadel-86 (keeping
     in mind the mentioned caveat).  This option is inoperative if you are not
     using the remote sysop password parameter (#sysPassword).

        A command line option not matching any of those listed so far
     is known as the 'crash' option.  It will cause CTDL to leave a message in
     your Aide> room informing you Citadel-86 apparently came up from a
     crash at the time of the message.  This is useful for batch files.

     II.10.b BAT files and program termination ERRORLEVELS
        MS-DOS BAT files depend heavily on the concept of ERRORLEVELs, and we
     encourage you to read the MS-DOS manuals for a full explanation of BAT
     files. The CTDL program, on termination, will set the MS-DOS ERRORLEVEL
     level to a value you can use to write useful BAT files; you may also
     cause other ERRORLEVELS to be set, as explained earlier in this manual.
     The values indicate the reason Citadel-86 terminated, and the ones
     reserved by Citadel-86 are discussed here.  Feel free to use other
     ERRORLEVELS at your discretion.

     0 -- A normal exit.  This indicates the sysop took the system down
          via e<X>it on the Sysop's menu (see OPER3.MAN for an explanation
          of the sysop menu).
     1 -- Exit due to detecting the existence of CTDLLOCK.SYS, which indicates
          this installation is already "up."  Normally, this means
          you used the <O>utside commands (see the Sysop's Manual) to go to
          the MSDOS shell, leaving Citadel-86 up but inactive, and attempted to
          bring your system back up, rather than typing 'exit'.  This is a
          failsafe so you do not accidentally bring Citadel-86 up within





                                    -40-




          itself.  Occasionally, you may be using <O>utside commands to do
          something when you are forced to reboot (power outage, program
          crash, etc.), in which case the CTDLLOCK.SYS file is no longer
          accurate.  In cases like these, the correct procedure is to delete
          CTDLLOCK.SYS and then attempt to bring Citadel-86 up again.

     2 -- This was a crash exit.  Citadel-86 is capable of recognizing a number
          of fatal internal errors; when any of them are encountered,
          Citadel-86 will hangup the current caller and immediately terminate
          with this value.  If a crash of this sort occurs, CONFG should be
          run before attempting to run CTDL again.  Some (not all) of these
          fatal errors include non-existence of CTDLTABL.SYS (very, very
          common, due to power failures), missing system files (such as the
          message file, etc.), and corrupted internal data, which indicates
          the possibility of a bug in CTDL.  Some of these crashes will leave
          the files CRASH and AUDIT behind, which can give hints on what's
          wrong (particularly CRASH).

     3 -- A remote sysop exit.  Since an Aide can be given access to the sysop
          menu from remote (see Section II.6.c on the parameter #sysPassword),
          s/he is capable of taking your system down from remote.  A number of
          sysops indicated it might be useful to distinguish between a
          sysop exit and a remote sysop exit, so this ERRORLEVEL is supported.

     4 -- This is a Door exit, indicating the current user has requested
          access to a Door (program) which you have provided via the #door
          parameter.  When your BAT file receives this Errorlevel, it need only
          do two things (essentially): run the program C86DOOR, and then loop
          back around to bring Citadel-86 up.

        One more note.  When you write a BAT file, make sure you handle
     the ERRORLEVELS in a "top to bottom" manner.  DOS will not process the
     ERRORLEVELS correctly otherwise.

     II.10.c Making BAT files and command line options work for you.
        No program is ever bug-free.  However, it is nice to pretend one
     is, and an effective way to pretend a particular program has achieved
     such a goal is by never having it require your attention when you are
     attending to other things.

        Citadel-86 tries to emulate this sort of utopian software by returning
     a value to MS-DOS when it terminates gracefully, as we described above,
     which allows you to construct BAT files handling most contingencies.

        Basically, we have to handle 'emergency' situations, which consist of
     coming up from a reboot and handling a graceful crash, and handling
     non-emergencies, which are coming out of C-86 in response to timeouts,
     sysop exits, remote sysop exits, and Door exits.

        First, let's look at the emergencies.  Typically, an emergency never
     happens at a convenient time; instead, you're off on vacation, at work,
     or feeding the cat.  Therefore, the software has to handle the emergencies
     on its own, within limits.

       In both of our emergency situations, the system must go through a CONFG
     call. When we looked at the command line options of CONFG, we saw a
     nonsensical argument on CONFG's command line tells it not to ask for




                                    -41-




     operator input regarding whether the system should be erased, but rather
     to simply re-analyze the data in preparation for a CTDL call.  Therefore,
     part of our BAT file strategy will contain the line

     CONFG gleeeeepy

     which we may end up placing in its own BAT file.

        Looking into the section on ERRORLEVELs, we should have also noticed
     one of the events causing a graceful crash is the absence of
     a CTDLTABL.SYS file.  Thus, we can classify a power down as simply another
     graceful crash -- after we make some modifications to your boot disks
     AUTOEXEC.BAT.  But first let's look at just how we should handle these
     'graceful crashes'.

        We said a graceful crash produces an ERRORLEVEL of 2.  With this
     in mind, we can put in one of our BAT files some lines looking roughly
     like this:

     CTDL
     ...
     if ERRORLEVEL 2 Fixit

     Fixit, in this case, is another BAT file which will fix the system for us.
     I.e., it runs CONFG and gets the system back up on its feet.  What should
     it look like?  Well, first we want to start the file as mentioned above:

     CONFG Gleeepy

     Once CONFG finishes, we need to restart CTDL.  As it happens, MSDOS BAT
     files do not 'stack' up; if A.BAT calls B.BAT, when B finishes it does
     NOT return to A, but instead falls out to MS-DOS.  This makes it easy to
     write BAT files to accomplish our purposes.  Suppose we call our main BAT
     file RUNIT.BAT (the file containing the 'if ERRRORLEVEL 2 Fixit' line
     in it).  Then we can simply finish the FIXIT.BAT file with

     RUNIT CRASH

     We'll explain the CRASH command line option later.

        What about the rest of those ERRORLEVELs?  Well, let's solidify your
     RUNIT.BAT a little more.

     CTDL
     if ERRORLEVEL 5 goto timeout
     if ERRORLEVEL 4 goto door
     if ERRORLEVEL 3 goto remote
     if ERRORLEVEL 2 Fixit
     if ERRORLEVEL 1 goto lockfile
     if ERRORLEVEL 0 goto alldone

        (Note the descending order we use here.  This is necessary due to the
     method MS-DOS uses to handle 'if' statements.)  This was simple -- we just
     put off all the work.  However, most of the work is yours, because it is
     really up to you to figure out what you wish to do when your system
     times out (CtdlCnfg.Sys's #event parameter -- we simply assumed you
     used a 5 in the <depends> field of an external #event parameter) and when
     your remote sysops bring your system down.



                                    -42-




        So let's flesh out the rest of this sample RUNIT.BAT.

     :loop
     CTDL %1 ...
     shift
     if ERRORLEVEL 5 goto door
     if ERRORLEVEL 4 goto timeout
     if ERRORLEVEL 3 goto remote
     if ERRORLEVEL 2 Fixit
     if ERRORLEVEL 1 goto lockfile
     if ERRORLEVEL 0 goto alldone
     :door
     C86door
     goto loop
     :remote
     REM put here what you want remote terminations to cause to happen.  If you
     REM want to rerun CTDL, you'd have 'goto loop'.

     :timeout
     REM put here what you want timeouts to do (backups or whatever)

     ...
     REM we assume you'd want to restart Citadel-86 afterwards.
     goto loop
     :lockfile
     REM here you tried to bring Citadel-86 when it already seems to be up.
     goto unknown
     :alldone
     REM And now the sysop at the console took us down, so we'll die.

        Most of this should be pretty easy to understand.  The '...' on the
     CTDL command line simply means whatever options you choose to put on the
     line. However, the '%1' may be puzzling.  As the MS-DOS manual indicates,
     %1 is the first argument on the command line of this BAT file.  Now,
     let's look back at the FIXIT batch file, where we put RUNIT CRASH.  This
     will force the parameter CRASH to appear on your CTDL command line, which
     CTDL will interpret as a 'nonsense' argument, therefore causing a 'crash'
     message to appear in your Aide> room.  Since it was the FIXIT batch file
     ultimately causing this message to appear, this is good behavior.

        But what of the SHIFT following the CTDL command line?  This causes
     the RUNIT command line arguments to shift 1 to the left.  Since there were
     no more arguments to RUNIT, any executions of CTDL subsequent to the SHIFT
     call, while within this BAT file, will not result in messages in the Aide>
     room.  And why might there be any more calls to CTDL after the first one?
     Look at the commands following the timeout label.

        This is just an example.  Have fun.

     II.10.d Result Code and Call Progress Detection
        One of the problems with the external serial interface of the IBM PC
     and its clones is its inability to directly detect the speed a modem
     has made connection with a caller via the RS232 interface.  Therefore,
     Citadel-86 can detect baud rates by reading the result codes most Hayes
     modems spit out.  This section details what you must do to use this
     capability.





                                    -43-




        There are two things you must do to attempt to use your modem's
     result codes for autobaud detection (please note some modems are so
     awful you can't use their result codes to accomplish autobaud detect).
     First, your modem must be configured to return result codes.  Typically,
     you do this using the #modemSetup parameter of CtdlCnfg.Sys, and the Hayes
     command is usually "ATQ0".  However, you should consult your modem's
     manual during these machinations and incantations.

        Further, you may need to decide if you want the result codes to be
     returned in Verbose mode or Non-Verbose mode (ATV1 and ATV0).  While
     Citadel-86 can use either mode if correctly configured (to be explained),
     you may have some preference.

        The second task is to inform Citadel what the result codes will be.
     Not all "Hayes compatible" modems return the same result codes for the
     same results.  Therefore you must provide them.  How?

        By constructing a simple text file named RESULTS.SYS.  It must reside
     in your #ROOMAREA (CtdlCnfg.Sys) directory, and it must be a normal MS-DOS
     text file.  Within it you place lines of the following format:

     #<result code identifier> <result code value>

     A "result code identifier" is one of a list of Citadel-86 supported
     identifiers for result codes, while "result code value" is the string
     your modem will return for that identifier.  The identifier is contained
     from the "#" sign to the first space (and there should only be one space,
     no more), while the result code value is contained from the character
     following the space to the end of line (thus allowing spaces in the result
     code value).

        For example, one of the identifiers is RESULT-300, which Citadel-86
     uses to identify a 300 baud caller, and most Hayes compatible modems
     we are aware of return CONNECT when a caller connects at 300 baud.  In
     order for the autobaud to use that value to identify a 300 baud caller,
     you would place the following line in your RESULTS.SYS file:

     #RESULT-300 CONNECT

     We, of course, assume you have your modem configured for Verbose
     mode.  If you are using Non-Verbose mode, and your modem returns 1 for a
     300 baud connect (a typical string for Hayes compatible modems, again),
     then you would place

     #RESULT-300 1

     in the RESULTS.SYS file.  But what if you weren't sure if your modem is
     going to be in Verbose or Non-Verbose mode during operation, for some odd
     reason?  Well, it is perfectly valid to have BOTH of those strings in
     RESULTS.SYS, and each will be used as needed!

     #RESULT-300 1
     #RESULT-300 CONNECT








                                    -44-




     Now that may sound somewhat trivial, but it is only an example.  A valid
     real-world example involves MNP capable modems.  Some of these modems
     return differing result codes, dependent on whether the caller is using
     an MNP modem or not.  For instance, a normal caller at 2400 baud will
     cause the modem to return CONNECT 2400, but a MNP caller at 2400 baud will
     cause the modem to return CONNECT 2400 RELIABLE.  Here is where the
     ability to place both of those results in RESULTS.SYS (or even all 4 if
     you want to cover both Verbose and Non-Verbose modes) can come in real
     handy.

     #RESULT-2400 CONNECT 2400
     #RESULT-2400 CONNECT 2400 RELIABLE

     AUTOBAUD IDENTIFIERS
        The following are valid autobaud identifiers, and any of them may
     appear more than once with different values as desired.

     #RESULT-300
     #RESULT-1200
     #RESULT-2400
     #RESULT-4800
     #RESULT-9600
     #RESULT-14400
     #RESULT-19200
     #RING

        #RING is used to identify rings, which can be useful.  The autobaud
     identifiers are used when a caller has been detected.  Other results, such
     as the Call Progress results which are about to be discussed, are
     discarded during autobaud detection in favor of searching for Autobaud
     strings.

     CALL PROGRESS IDENTIFIERS
        Some modems can support call progress detection when configured
     correctly.  (Call progress detection is the ability to recognize no
     dialtone, busy signals and other such minutae.)  Citadel-86 can use those
     result codes if available to speed dialing during both networking and
     during use of the <D>ialout option of the Network menu.  The format of
     these identifiers are the same as the Autobaud identifiers.  The list of
     valid identifiers:

     #DIALTONE
     #NO-DIALTONE
     #OK
     #NO-CARRIER
     #BUSY

        The values you specify for #NO-DIALTONE, #NO-CARRIER, and #BUSY,
     when detected during callout, will cause Citadel-86 to conclude the
     call was unsuccessful and therefore abort it.  As with the Autobaud
     identifiers, you may specify any of these parameters multiple times to
     cover multiple situations.  For example, if your modem returns BUSY when
     a busy signal is detected, you would place

     #BUSY BUSY

     in your RESULTS.SYS.




                                    -45-





     II.10.d.1 Restrictions on Result Codes
        Unmodified Zenith Z-100s are incapable of reading and using Hayes
     result codes due to the hardware implementation of the serial port.
     Modifications can be made to the cable connecting the Z-100 to the modem
     and to your CtdlCnfg.Sys allowing the use of Hayes Result codes.
     Please see the special section in this manual regarding Z-100
     peculiarities.

     II.10.e Extreme options in CtdlCnfg.Sys
        Some of the modem I/O routines in Citadel-86 can be changed by the
     adventurous sysop via the CtdlCnfg.Sys file.  Normally, Citadel-86 uses
     built-in modem routines designed to handle the normal situations of Z-100s
     and the two COM ports of PClones.  However, they can be replaced through
     manipulation of CtdlCnfg.Sys.

        When do you want to use these options?  NEVER, really.  But you
     probably do when you have an unusual, but not unique, modem setup.  If you
     feel your modem connection is really, really odd, you may wish to acquire
     the source code for Citadel-86 and perform some hideous hacks of your own.
     These options are useful when you wish to do something unusual with your
     installation.

        All right, what ARE these 'routines,' anyways?  They came from the CP/M
     version of Citadel, where they were the entirety of Citadel's modem I/O.
     To quote the old documentation that accompanied them, they "...implemented
     a virtual machine with a single accumulator", which is another way of
     saying a primitive psuedo-assembly language was made available to
     the sysop for designing their own modem I/O.  The reason they
     exist in Citadel-86 is partly inertia and partly their flexibility: the
     two types of machines Citadel-86 supports, Zenith Z-100s and most
     PClones, have radically different serial interfaces.  Using the
     appropriate routines saves some (probably only a trivial amount of) code
     room.

        OK, let's get concrete.  Each routine available to you is composed
     of two parts, the name of the routine and the code which implements it.
     Abstractly, it looks like this:

     #start <routine name>
     #code <instruction> <optional instruction data>
     #code <instruction> <optional instruction data>
     ...

        Usually, the last #code instruction will specify a RET.

        Here is the list of routines currently supported:

     HANGUP     -- This routine MUST force your modem to hangup.
     INITPORT   -- This routine should initialize your port AND your modem.
                   (NOTE: If INITPORT exists, #modemSetup should NOT exist.)
     CARRDETECT -- This routine MUST return (see the RET instruction) a 0 when
                   there is no carrier, and a non-0 value when there is
                   carrier.
     SET300     -- This routine should set your modem's port to 300 baud.
     SET1200    -- This routine should set your modem's port to 1200 baud.





                                    -46-




     SET2400    -- This routine should set your modem's port to 2400 baud.
     SET4800    -- This routine should set your modem's port to 4800 baud.
     SET9600    -- This routine should set your modem's port to 9600 baud.
     SET_HIGHER -- This routine should set your modem's port to your choosing
                   (this option may not be supported in the future).
     ENABLE     -- This routine must ENABLE your modem for answering the phone.
     DISABLE    -- This routine must DISABLE your modem from answering the
                   phone.

        The instructions available to you simulate a very simple machine with
     one accumulator and a scratch array.  You'll find the instructions crude,
     primitive, and limiting.  The scratch array is addressed from 0, and has
     40 elements.  Here they are:

     LOAD x   -- This instruction loads the accumulator with the value in
                 location x of memory (!).
     ANDI x   -- This instruction performs a logical AND of the accumulator
                 with x and places the result in the accumulator.
     ORI x    -- This instruction performs a logical OR of the accumulator with
                 x and places the result in the accumulator.
     XORI x   -- This instruction performs a logical XOR of the accumulator
                 with x and places the result in the accumulator.
     STORE x  -- This instruction stores the accumulator in the specified
                 address of memory(!).
     LOADI x  -- This instruction loads the accumulator with the value of x.
     RET   x  -- This instruction forces the routine to return to the caller
                 with the value of the accumulator (in this case, 'x' is just
                 a dummy value).
     INP x    -- This instruction causes the accumulator to be loaded with the
                 value currently present at port x.
     OUTP x   -- This instruction causes the accumulator to be sent to port x.
     PAUSEI x -- This instruction causes the Citadel-86 installation to pause
                 for x/10s of a second.
     ARRAY[]= x -- This instruction stores the accumulators value in the
                   specified location of the scratch array.
     ARRAY[] x  -- This instruction loads the accumulator with the value in the
                   specified location of the scratch array.
     OUTSTRING "x" -- This instruction causes the string "x" to be sent to the
                      modem.

     OPR# "x" low high -- This instruction causes the string "x" to be
                          displayed, followed by a request for a number.  Low
                          and high specify the lowest and highest acceptable
                          values.  The accumulator receives the value specified
                          by the user.

        In SUPPORT.LZH there should be a file named PSUEDO.DOC.  It contains a
     listing of all the default routines used by Citadel-86.  If you have ANY
     plans at all for using your own routines, first examine those in
     PSUEDO.DOC, both to understand what is used for a default, and for working
     examples of how to write valid routines.

        And, lastly, REALLY WE HOPE YOU DON'T HAVE TO ENGAGE IN THIS SILLINESS.








                                    -47-




     III. ZENITH Z-100 NOTES

     III.1 Introduction
        This section contains notes concerning the hardware configuration
     of Zenith Z-100s as it applies to Citadel-86.  Most, perhaps all, of
     these contributions were contributed by Sysops using the Zenith Z-100
     as their hardware, and the authors of this manual would also like to
     take this opportunity to thank Eric Brown, System Operator of Primordial
     Ooze, for providing the serial interface code for Borland's Turbo C
     (the current C dialect in use today for Citadel-86) for Z-100 hardware.

     III.2 Scary but Innocuous Behaviors
        First off, whenever Citadel-86 is brought up on a Zenith Z-100, the
     System Operator will note his or her screen is decorated with a
     series of four "WILD INTERRUPT" messages.  The experienced Z-100 owner
     will recognize these as the normal prelude to a full system crash.
     However, in the case of Citadel-86, this is not true.  It would appear
     Borland's Turbo C, when compiled and linked for Large model (which
     is what we use for Citadel-86), causes the Z-100 to generate these
     messages but does no actual harm to the system.  Several Z-100 BBSs have
     been running for months now, and have suffered no problems, so, when you
     see these messages, ignore them.

     III.3 Result Codes
        The following was contributed by K-9, System Operator of the Dog House
     BBS, for which we thank him.

     Written by K-9,
     The Dog House BBS
     612/460/6056

     11/28/87

      When you are using a communications program written for the PC on a Z-100
     certain RS-232 characteristics that are different will prevent their use.
     To overcome the difficulties the communications routine used with the
     Z-100 had to be different than with a PC.  As a result when the AUTO-BAUD
     DETECT feature was released the Z-100s weren't supported.  Thanks to
     information I had on the differences in the port and Hue, Jr.s prowess
     with the coding the feature is now supported on Z-100s.

      To connect an autodial modem to jack J2 and support AUTO-BAUD DETECT you
     need to know how the Z-100 RS-232 port functions.

      To make any autodial modem dial, you type commands which are sent out
     your port to the modem; ideally, both what you type and the verbal
     responses which come back from your modem should appear on your screen.
     While a Z-100 won't prevent commands you type from getting to your modem,
     it won't display anything from the modem until the modem indicates it has
     linked up with a remote system, ie. has Carrier Detect high.

      Actually, what causes a Z-100 to act this way is that a Z-100 won't let
     anyting come into it's J2 port while your modem is applying a negative
     signal to pin 8 on the port.  Data is allowed to enter only when no signal
     or a positive signal is applied to pin 8.






                                    -48-




      What is normaly attached to pin 8 is an output from the modem called
     Carrier Detect (CD or DCD, for short); carrier detect is negative when
     the modem isn't linked with a remote system, and positive when it is.
     While Citadel needs these outputs for AUTO-BAUD DETECT, the unpleasant
     side-effects are untolerable.

      The solution is to modify your cable so that the modem's DCD output is no
     longer attached to pin 8 on your J2 connector, but is available to Citadel
     on pin 6, instead.  This modification won't damage anything, and won't
     have any adverse effect on performance of the computer.

      The procedure is different depending on whether or not the modem is a
     Hayes Smartmodem compatible.  The exact mechanics of making this modi-
     fication depends on your cable and modem.

      1.  Begin with by attaching the cable between the modem and the J2 port
     at the modem end.  Open up the connector.  Find the wire that goes to
     pin 8 (there are tiny numbers on the face of the plug).  Cut that wire
     close to the back side of the plug.  If you are using a Hayes Smartmodem
     or US Robotics Password you can skip the next two steps.

      2.  Find the wire that goes to pin 6.  Cut it, leaving a length of about
     1 inch still attached to the pin.

      3.  Strip the insulation from the end of the wire that did go to pin 8.
     Also, strip the wire still attached to pin 6.  Twist the two wires
     together and then solder (preferably) or tape them together.  Make sure no
     bare wires are exposed.

      4.  Re-attach the cable to the modem.  You are finished with the hardware
     modification if you have the modem switch settings set proper.  Normal
     switch setting recommendations for the modem still apply.  Only change you
     will need to make with the modem is to enable result codes which are
     normally disabled and have digits vs. verbose (word) responses enabled.
     The CtdlCnfg.Sys file as distributed with V3 supports the digit codes.

      You can also change the result codes via your modem initialization string
     by setting the following values:

      The Q value should be changed to 0 (Q0) to mean result codes will be sent

      The V value should be changed to 0 (V0) to send result codes as digits

      There are some additional changes which need to be made to the
     CtdlCnfg.Sys file to use AUTO-BAUD DETECT.

      Good luck!

      K-9












                                    -49-





                                ctdlCnfg.sys


        This is the configuration file for the Citadel-86 bulletin board
     system. It is read in by confg.exe which sets up a "ctdlTabl.sys" file
     recording the configuration parameters.  (CtdlTabl.sys is read by the
     other Citadel programs.) This file must be edited to be appropriate to
     the local environment. Lines not beginning with "#" are ignored by CONFG
     and may be deleted once the file is successfully configured -- they are
     purely documentary.  For more detail, consult the CITADEL-86 SYSOP MANUAL.

     GENERAL STRING FORMATTING CONTROLS:
     The following are supported:
             "\n": CR-LF
             "\t": Tab character
             "\b": Non-destructive Backspace
             "\r": CR
             "\f": Formfeed
             "\"": '"'
             "\\": Backslash
             "\<xxx>": The octal* ASCII value is output

        SECTION 1: NECESSITIES AND MISCELLANEA

     SYSTEM TITLE
        nodeTitle is printed after the "Welcome to" and before the "Running..."
     lines of the banner that pops up on carrier detect, UNLESS BANNER.BLB
     exists, in which case the entire "Welcome to <nodeTitle>" line is
     replaced with the contents of BANNER.BLB.  nodeTitle is a string value
     that accepts formatting directives and goes through the Citadel
     formatter.

#nodeTitle "Our Name"         -- An obvious imposter

     SYSTEM NAME
        nodeName is purely for networking purposes.  Messages which
     originated on your system will have headers looking like:

           82Nov23 From Cynbe ru Taren @ODD-DATA

     This should be a short (for the sake of the reader!) mnemonic
     identifying your node for humans.  It does not use formatting directives.

#nodeName "ODD-DATA"          -- The original Citadel (kow-tow, everyone)

     SYSTEM ID
        nodeId is also purely for networking purposes.  Messages which
     originate on your system will be marked with the nodeId, but it will
     not normally be printed out.  It is primarily for the use of the
     networking support software, and forms a globally unique name and
     address for your system.  It consists of a country abbreviation
     followed by area code and system phone number.  This string value does not
     use formatting directives. Country abbreviation for the US is "US", for
     Canada is "CA".  (For others, see COUNTRY.DOC.)


#nodeId "US 612 470 9635"



                                    -50-




     SYSTEM BASEROOM
        baseRoom is the homeroom of the Citadel in operation, the place you
     go when there are no more rooms with unread messages left.  This is
     usually known as the Lobby> on most systems.  It's simply a nice,
     easy way to customize and give character to your system..

#baseRoom "Glops"

     SYSTEM BASE FLOOR
        MainFloor is the home floor of the Citadel in operation, the floor
     where baseRoom, Aide, and Mail are located.  It's another nice, easy
     way to customize your system

#MainFloor "Da Basement"

     SYSTEM ENCRYPTION SEED
        CRYPTSEED is a number used in encrypting the data files.  Change
     it once when you install the system, but not thereafter -- or you
     won't be able to read the existing files any more.

#CRYPTSEED 333                --

     UNLOGGED USER'S SCREEN WIDTH
        This parameter is used to specify an unlogged user's screen width
     (including banner display).  If not present, defaults to 40.

#UNLOGGED-WIDTH 79

     DATA FILES SIZE: MESSAGE BASE
        MESSAGEK sizes "ctdlmsg.sys", the file message text is stored in. The
     size of this parameter together with the rate at which message text is
     entered determines message lifetime.

#MESSAGEK 300                 -- 300Kbyte ctdlmsg.sys

     DATA FILES SIZE: MESSAGES PER ROOM
        MSG-SLOTS defines the maximum number of displayable messages per room
     on your room, except for the Mail> room.

#MSG-SLOTS 58                 -- 58 is kind of traditional

     DATA FILES SIZE: MESSAGES PER MAIL ROOM
        MAIL-SLOTS defines the maximum number of displayable messages for each
     user's Mail> room.

#MAIL-SLOTS 58                -- Yet another tradition...

     DATA FILES SIZE: ROOM FILE
        MAXROOMS defines the maximum number of rooms on your system.

#MAXROOMS 64                  -- This is usually enough










                                    -51-





     DATA FILES SIZE: LOG FILE
        LOGSIZE is the number of entries that you want in your log. Once
     you've selected a log size and have configured, you may NOT shrink
     the log except by destroying the log totally. There is a utility
     available for expanding the log, called DATACHNG.

#LOGSIZE 180                  --

     **DATA FILE LOCATIONS**
        The next several parameters allow you to specify where certain system
     files are to appear on your system.  Please note that only subdirectories
     of the disk you specified are legal.  Disk specifications are legal.

        This parameter specifies where you want your help files located in your
     system.

#HELPAREA "helps"             -- All help files located in subdir
                              -- "helps"

        This applies to the CTDLLOG.SYS file.

#LOGAREA "a:log"              -- in subdir "log" on drive a:

        This applies to the CTDLROOM.SYS, CTDLBAD.SYS, and CTDLARCH.SYS files.

#ROOMAREA "system"            -- in subdir "system"

        This applies to the CTDLMSG.SYS file.

#MSGAREA ""                   -- current directory of default disk

        This applies to the CTDLFLR.SYS file.

#FLOORAREA "floors"           -- its own subdirectory for no particular reason.

     AIDE SCOPE:
        The AIDESEEALL parameter controls the scope that Aides have on the
     installation.  If this parameter is set to 0, then Aides are only allowed
     to see public rooms and private rooms that they are told about;
     private room creation will leave an entry in the Aide> room indicating
     that a room was created, but not the name.  An Aide at the SysConsole
     will, however, see all rooms.  If this parameter is set to 1, then all
     Aides will see all rooms on the system, public or private.

#AIDESEEALL 0                 -- Aides see nothing

     NEW USER CONTROL:
        LOGINOK controls whether users without a password can login from
     remote. If LOGINOK is 1, they may; if LOGINOK is 0, then the only place
     that new accounts may be entered is from the system console.

#LOGINOK 1                    -- user-established accounts








                                    -52-





     MESSAGE ENTRY CONTROL:
        If ENTEROK is 1, callers that are not logged in may enter messages.  If
     0, then they must login first before they can enter messages (except for
     Mail> to the Sysop.  Note that Anonymous rooms are not an exception.

#ENTEROK 0                    -- login first

     READING CONTROL:
        If READOK is 1, then unlogged callers can read messages.  If READOK is
     0, then users must login before reading messages.

#READOK 0                     -- login first

     ROOM CREATION CONTROL:
        If ROOMOK is 1 then regular folks can create new rooms, else only those
     with aide privilege can do so.

#ROOMOK 1                     -- general room-creation privileges

     MAIL CONTROL:
        If ALLMAIL is 1, all get privileges; 0 means only aides have the
     privilege.

#ALLMAIL 1                    -- Everybody can send mail

     INITIAL DOOR PRIVILEGES
        If DoorPrivs is 0, then users must ask for door privileges; otherwise,
     they automatically have them on initial login.

#DoorPrivs 0                    -- A prudent policy; also, the default.

     INITIAL FILE PRIVS
        Use this parameter to decide if people have file download privs
     when they first logon or if they have to request them.

#FILE-PRIV-DEFAULT   1        -- yes

     COMPUTER HARDWARE TYPE:
        Setting IBM to 1 implies the system is a PClone, and to use some
     internal routines for accessing modem.  If IBM is 0, then substitute
     other special routines specific to the Z100 for accessing modem.

#IBM 1                        -- IBM clone

     COM PORT:
        The COM parameter allows the sysop who is using an IBM to select
     either COM1 or COM2 as the communications port. This parameter is
     meaningless for Z-100s.

#COM 1                        -- COM1 is the selection










                                    -53-





     SYSTEM BAUD RATES:
        SYSBAUD defines the baud rates supported by this installation.  Use
     these values to indicate what maximum baud rate your system runs at:

        0 - 300 baud
        1 - 1200
        2 - 2400
        3 - 4800
        4 - 9600
        5 - 14400
        6 - 19200

#SYSBAUD 1                    -- A 3/12 system.

     MODEM INITIALIZATION:
        modemSetup specifies what should be sent to the modem after
     initializing the port. While Hayes/compatibles are recommended, other
     types of modes have been successfully used with Citadel-86, such as
     TransModems.

#modemSetup "AT S0=1 M1"

     MODEM REINITIALIZATION:
        REINIT lets you reinitialize the modem after each call at the highest
     baud rate the modem will recognize.  If this parameter is not present,
     then the modem will not be reinitialized.  Formatting directives are
     recognized.

-#REINIT "AT"

     MODEM MANAGEMENT
        Citadel-86 normally drops DTR (for novices, on most modems this causes
     the modem to drop carrier and disables auto-answer until DTR is brought
     back up) when it doesn't want a caller calling in.  This typically
     happens when the system operator logs in at the console or the system
     is digesting messages from a network session.  You can modify this
     behavior by defining the two strings below, and they come into action
     only when the system operator logs in at the console (i.e., when you
     touch ESCape).  The first string, #DISABLE-MODEM, is sent to the modem
     when you touch the ESC, while the second, #ENABLE-MODEM, is sent when
     you put the system back into MODEM mode.  They let you do such things
     as take the modem off-hook (generate a busy signal) when you are using
     the system.  One note: the system will NOT add carriage returns to these
     strings automatically, so make sure you do!

-#DISABLE-MODEM "ATH1\r"    -- This would take the modem off hook
-#ENABLE-MODEM "ATH0\r"        -- This would put the modem on hook













                                    -54-




     PORT LOCKING
        You can have your installation "lock" the serial port at a given
     speed and let the modem handle details concerning buffering, etc.  On
     some modems such as USR HSTs, etc., this can result in a measurable
     increase in through-put; for some modems, you HAVE to do this in order
     to use the higher speeds.  HOWEVER, you have* to know what you're doing
     or you shouldn't do this.  This parameter has a numeric value which
     specifies the baud rate to lock the port at, just like #SYSBAUD.  You
     should consider using #REINIT to instruct the modem about your port
     locking, so that everytime the modem is told to hung up it is reminded
     about the port locking.

-#LOCK-PORT  4            -- This would lock it at 9600 baud


     OLD VIDEO
        As noted in INSTALL3.MAN, some systems don't like Citadel-86 video
     support.  If your system doesn't, enable the following parameter.  Note
     the lack of value after the name -- that's on purpose!

-#OLDVIDEO              -- disabled.


     SYSTEM SCREEN COLORS
         FOREGROUND
         BACKGROUND
         STATUS-FOREGROUND
         STATUS-BACKGROUND
        These parameters allow control of the foreground and background colors
     of the screen, including the status bar.  See INSTALL3.MAN for a full
     list of supported colors.  The generic setup should cause the status bar
     to have black letters on a gray background, while the rest of the screen
     is white letters on a black background.  See the Ease utility for an
     easy way to select colors.

#FOREGROUND WHITE
#BACKGROUND BLACK
#STATUS-FOREGROUND BLACK
#STATUS-BACKGROUND LIGHT GRAY

     STATUS BAR CLOCK
        Normally, the status bar has a clock which is updated each minute.
     You may control its behavior by using one of the values "None", "Inuse",
     or "Always" in the #CLOCK parameter.

-#CLOCK Always                     -- disabled.


        SECTION 2: INTERESTING OPTIONS

     TIMED EVENT HANDLER:
        See the manual for this one.  Here is the generic format:

-#event <days> <time> <class> <type> <duration> <warning string> <depends>







                                    -55-





     REMOTE SYSOP FACILITY:
        #sysPassword specifies the file that contains a string that will act
     as the password to the remote sysop abilities.  If this parameter is not
     specified, or if the file is not found, or is unreadable, then remote
     sysop abilities are disabled.  Only Aides can access remote sysop
     abilities, and they must* know the exact password, including the case
     of the individual letters.

-#sysPassword "c:\pwd"        -- Inactive (note the leading hyphen)


     AUDIT:
        This parameter specifies where the files CALLLOG.SYS, FILELOG.SYS, and
     DOORUSE.SYS end up on your system.  Note that the directory specified has
     to be a subdirectory of a current directory.

-#AUDITAREA ""                 -- put CALLLOG.SYS in the current directory
                               -- (inactive -- note leading hyphen)

     ANONYMOUS CALLERS
        This parameter, if enabled, logs ANONYMOUS callers from remote in
     your CALLLOG.SYS as "<No Login>".

-#ANONYMOUS-SESSIONS


     RAM DRIVE HANDLING:
        These two parameters control whether or not and where a secondary
     message file will reside.  If you use this parameter, it should
     reference a permanent media file, and the MSGAREA parameter should
     reference a RAM drive.  MSGAREA will always be both read and written to,
     while this one will only be written to; thus, this parameter should
     reference the media more sensitive to wear and tear.  MIRRORMSG should
     be 1 if you wish to use this ability; MSG2AREA then referrnces the
     location of the secondary message base.

#MIRRORMSG 0                  -- Turn it off for novices
#MSG2AREA ""                  -- so this is irrelevant while MIRRORMSG
                              -- is 0

     INTERRUPTED MESSAGE AREA:
        This parameter specifies where to save interrupted messages for
     later completion.

-#HOLDAREA "held"             -- inactive

     SYSOP MAIL ROUTING:
        This parameter specifies the account that Mail> to sysop should be
     routed to.

 -#sysopName "Me!"            -- inactive









                                    -56-





     OUTSIDE EDITOR:
        These parameters specify what editor the Sysop may use for System
     Console message composition, and what area of the disk system to use for
     temporary files.  If the first is not present, then the <O>utside Editor
     is not available; if the second is not present, the current drive and
     directory are used for temporary files.  See OPER3.MAN and INSTALL3.MAN
     for full details.

-#EDITOR "whatever"             -- disabled!
-#EDIT-AREA ""                  -- ditto!

     Citadel-86 as a Door:
        This parameter lets you tell the installation that Citadel-86 is a
     door itself.  In this situation, the modem is not initialized, etc...
     See OPER3.MAN Section XII for details.

-#ISDOOR                        -- disabled, no value for this parameter.

     CONSOLE TIMEOUT
       If you are in the habit of forgetting to logoff when you're at the
     console, thus effectively making the system useless until you notice
     your indiscretion, you can use this numeric parameter to decide how
     many SECONDS the system can be inactive while in CONSOLE mode before
     logging the person off at the system console

-#CONSOLE-TIMEOUT  600        -- this would be a 10 minute timeout period

     CONSOLE DELAY
         Having problems keeping up with Citadel-86 at the console when you're
     logged in there because the screen is just so dratted fast?  This
     parameter is just like .ECD: you can have the system pause for xxx
     milliseconds after each character is put out when the user (whoever it
     may be) is at the system console.

-#CONSOLE-DELAY  1        -- This would make for a one second delay

     SYSOP MAIL
        You can archive sysop mail.  This string parameter specifies the file
     Sysop Mail should be archived to.  This includes both Mail> to "sysop"
     and mail to the name specified in #sysopName.

-#SYSOP-ARCHIVE "sysop"    -- mail archive filename

     ANONYMOUS MAIL CONTROLS
        Anonymous mail to sysop is occasionally used to abuse systems.  This
     numeric parameter is used to control the maximum length of anonymous
     mail.  If an anonymous mail leaver exceeds that length, the user loses
     carrier and the mail, instead of being placed in mail, is placed in a
     file named ANONMAIL and a message is left in Aide informing you of this
     fact.

-#ANON-MAIL-LENGTH  300        -- anonymous folk will have to be brief








                                    -57-





     PASSWORD HACKERS
         Village Idiots being a pain?  This numeric parameter lets you tell
     the system to drop carrier on anyone who screws up their password X
     times.

#LOGIN-ATTEMPTS  5


        SECTION 3: NETWORK PARAMETERS

     NETWORK SELECT:
        You use this parameter to decide whether or not you are a networking
     system.  If you set this parameter to 0, then the rest of the parameters
     in this section are meaningless, because you are not a networking
     system.

#NETWORK 0                    -- Disable for novices

     YOUR DOMAIN
        What domain are we located in?  One to a customer, please.  See
     NETWORK3.MAN for more information on domains.

#nodeDomain "xx"

     MAIL ROUTING:
        If #RouteMail is 0 then you categorically refuse to route mail for
     anyone to anywhere; if 1, then you will route, although you may place
     individual limits on certain systems.

#RouteMail 1                    -- default, too

     MAIL HUB
        A mail hub is a system you send all domain-oriented mail to when
     you don't know how else to get to the given domains.  This string
     parameter is the name of a system on your primary nodelist.

-#MailHub "xxxxx"        -- local backbone?  another backbone?

     NEW USER NET PRIVILEGES:
        #NewNetPrivs specifies whether or not new users automatically have
     net privileges.

#NewNetPrivs 0                -- Nope.

     DOMAIN DISPLAY
        This very optional parameter lets you customize how the domains on
     messages from other systems are displayed.  The default is shown
     in our example.  Note the '%s' MUST be present.

#DomainDisplay " _ %s"

     DOMAIN SERVING
        You want to be a domain server?  This is how you volunteer; set this
     parameter to tell what domain you want to serve, and see NETWORK3.MAN on
     administrative procedures.

-#ServeDomain "xx"        -- make sure you know what you're doing



                                    -58-





     NET FILES LOCATION:
        You use this parameter to specify where the various network-related
     files will be located.  It is a string parameter that you use to specify
     the drive and directory to put these files.

#NETAREA "c:net"              -- an example ONLY

     DOMAIN FILES LOCATION
        This parameter lets you decide where to put domain-related temporary
     files.  We recommend you make this different from #NETAREA.

#DOMAINAREA "c:domains"

     MAXIMUM SHARED ROOMS:
        This parameter selects the maximum number of shared rooms per system.

#SHARED-ROOMS 1

     RECEPTION AREA FOR FILES:

        The NET_RECEPT_AREA parameter specifies the directory that files sent
     to this installation Via the Send File feature of the net will be placed
     in.  Do NOT end it with a '\'!

#NET_RECEPT_AREA "C:\citadel\recept" -- Just an example

     RECEPTION DIRECTORY SIZE:
        The parameter NET_AREA_SIZE allows the sysop to specify how much room
     should be allocated for the NET_RECEPT_AREA parameter.  This allows the
     sysop to ensure that his system isn't swamped by files sent by other
     systems. The NET_AREA_SIZE parameter should be in K. (Remember, this
     should be in hex.)

#NET_AREA_SIZE 500

     INCOMING FILES SIZES:
        The MAX_NET_FILE parameter allows the sysop to decide how large of a
     file the system will accept from another system when the file is sent
     by the other system (this does NOT apply to Requesting a file, only to
     accepting a file Sent with the Send Net feature). This parameter is
     also in K.

#MAX_NET_FILE 300

     MODEM DIALOUT:
        callOutPrefix determines what is output to the modem prior to
     the phone number to be dialed.  It must send all commands necessary
     to put the modem into dial out mode.  Additionally, it must contain
     what is neceessary in the way of special commands dealing with PBX's,
     etc.

        #callOutSuffix determines what is output to the modem after








                                    -59-





     #callOutPrefix and the phone number has been output.  Graphically,

            <#callOutPrefix><phone#><#callOutSuffix>

     is the sequence in which data is out when the networker tries
     to dial out.  Since nothing is automatically appended to the
     number when it is being output to the modem during networking,
     the typical value for an installation using a Hayes/compatible is

            #callOutSuffix "\r"

     since Hayes/compatibles require a C/R to end a command string.

     This may not hold true for other brands of modems.

#callOutPrefix "ATDT"         -- Normal Hayes installation w/ TT.
#callOutSuffix "\r"           -- Typical Hayes suffix

     SPECIAL CALL OUT STRINGS
        Sometimes, for special baud rates, you want to use a different dialout
     string than what you're using #callOutPrefix.  These parameters can
     be used for that.

-#DialOut300 ""
-#DialOut1200 ""
-#DialOut2400 ""
-#DialOut4800 ""
-#DialOut9600 ""
-#DialOut14400 ""
-#DialOut19200 ""

     SCANNING INCOME NET MESSAGES
        Tired of profanity coming in on the net?  If this parameter is
     enabled, then incoming net messages are scanned against BADWORDS.SYS,
     and those failing the test are discarded with an appropriate note in
     the Aide> room.

-#SCAN-NET-MESSAGES

        SECTION 4: SPECIAL REQUIREMENT HANDLING

        NOTE: If you think you have an odd modem setup, such as a
     non-standard cable for allowing direct access to a high-speed pin, then
     consult the Citadel-86 SYSOP MANUAL, Section II.5.d, which details what
     abilities are available in this section of CTDLCNFG.SYS.  If that
     section is not clear, or doesn't seem to handle your particular problem,
     try to contact Hue, Jr. on the C-86 Test System [phone] for help,
     or his successors.

#alldone x x                  -- end of file










                                    -60-